Skip to content

Latest commit

 

History

History
43 lines (31 loc) · 2.28 KB

notes.org

File metadata and controls

43 lines (31 loc) · 2.28 KB

Notes and journal

notes

Alternatives to Phoenix: Maru (likely smaller than Phoenix and we are not leveraging most of the stuff phx can give us).

[2019-07-25 Thu 11:09] How should the format be requested by the user, and how should be honor that request?

  1. path segment: /api/json/matches and /api/protobuf/matches
  2. request param: /api/matches?format=json
  3. request header: curl -H “Content-Type: application/json” localhost:4000/api/matches and curl -H “Content-Type: application/octet-stream” localhost:4000/api/matches

If we go for the third option, which seems to be the one that respects most semantics, how should we honor the request server side?

  1. a plug to go side by side with the json plug?
  2. render(conn, “index.protobuf”, match: match) or whatever, add the pattern match in match_view.ex and use exprotobuf to return the right thing.

For now, we’ll go for 3 and 2.

[2019-07-25 Thu 11:24] SELECT DISTINCT division, season FROM matches; [2019-07-25 Thu 11:33] alternatively, get all matches from the matches table and use elixir list manipulation functions

[2019-07-26 Fri 16:09] Sentry could be used for logging?

At the end of it, the above mentioned solution of returning the “right” thing in match_view.ex was abandoned in favor of using Plug.Conn.send_resp/3 directly in the controller.

[2019-07-27 Sat 12:14] bureaucrat could be used to automatize API documentation

Dockerfile and docker-compose.yaml were built using mainly this and this resources as starting point.

Haproxy setup build using dockercloud/haproxy together with this and this tutorials.

docker build -t phoenix:v1 .

docker swarm init docker stack deploy –compose-file=./docker-compose.yaml fb

ip addr show docker0 curl -H “Content-Type: application/json” http://${DOCKER0_IP}:80/api/matches/SP1/201516