i never said jsonapi, i said “a json api” as in an api that communicates in json.
i still believe ajax with json might be a good choice for op, as they seem to be learning. read up on best practices about building a rest api and connecting that to a frontend and you pretty much have a step by step guide.
if you want to build the websocket / channels integration, you need to invent a lot yourself. the tools are all there, but best practices not so much, i think.
technically, you are all correct. websockets / channels will outperform ajax. i was looking more at the learning and documentation side.
Ah I see most people reference actual JSON API, sorry for the quick reaction. ^.^
In that case yeah, a simple JSON interface, or GraphQL (which returns json) would be great.
Hmmm such as? Take GraphQL over websockets, there are libraries out that simplify that trivially. Or just make the raw channel calls, which is simple json.
If I go down the Websocket route, is there any disadvantage to using the Sockets.io abstraction of Websockets for the VueJS side? Or am I just adding complexity? (I know nothing about either currently.)
Technically you would be using a Phoenix channel, which only uses web sockets if they are available, so you would want to stick with the Phoenix API - at least that is my understanding.
I’ve never used nor even heard of Sockets.io, so I could not say. ^.^
The Phoenix stock javascript is dead simple to use though.
Just make the calls via any normal way you would in vuejs, you could even sprinkle it around in the components directly (though putting them in another class and wrapping them lets you easily change it in the future, like to GraphQL over phoenix websockets or something).
Ok, when you are using “WebSockets” - but when you are using Phoenix channels (which by default use a WebSocket) you should use phoenix.js, socket.js. (Joining Channels)
The Phoenix socket abstraction is by default backed by a WebSocket - and you get a channel from the Phoenix socket.
The default transport mechanism is via WebSockets which will fall back to LongPolling if WebSockets are not available.
.
Phoenix holds a single connection to the server and multiplexes your channel sockets over that one connection.
Such as “Which channel do I join”?, “What message do I send to ask for a list of data?”, “What message do I send to ask for a specific resource?”, “What message do I send to create/update a resource?”, “How do I handle validation-/authorization-/other kinds of errors?” With a basic REST API, all of that is pretty clear. You can even have phoenix generate the basics for you. With channels I’m not aware of any established best practices for that, which I think is a big, big disadvantage WHEN LEARNING.
GraphQL is really cool, I’m using it myself. However, if you’re learning Phoenix and Vue, adding GraphQL will add another new thing you need to learn. And making it work with websockets/channels is yet another non-standard thing. There’s Absinthe.Plug, but I don’t know of an out of the box solution for GraphQL over channels.
There’s Absinthe.Plug, but I don’t know of an out of the box solution for GraphQL over channels.
I think graphql subscriptions (graphql over websocket) will be available in absinthe sometime soon [0][1]. Not sure if they are intended to complement or replace phoenix channels, though.
Whatever your want, that is also your creation. ^.^
Also whatever your want, that is your creation. ^.^
Ditto, sensing a pattern yet?
Not really, same decisions with rest. Names of endpoints, connections, what data can be served, how to query for it, etc… etc… etc..
That template is an example, it is not a full REST endpoint, it is for interacting with only a single schema, and I near never see just single schema’s asked for or queried for.
Phoenix has default templates for those too, but again it all depends on just ‘what’ you are trying to accomplish.
GraphQL is just a query, think SQL, but for JSON, still very succinct and simple, it is not bound to any specific transport medium, only that GraphQL is a request and it returns JSON. You can use it over endpoints, channels, raw TCP, whatever. And GraphQL is quite used, there is plenty of documentation on it out there. Using it with channels all I did was just have a single message that I named “request” and I just take the string from it and call absinthe with it and return the results, it is the same thing you do if it is on an endpoint (though it has a plug that can save you that step, though piddly a step it is).
GraphQL Subscriptions are a new GraphQL thing (not in absinthe, they are new in general), it just lets you basically ‘register’ to a query and you get the response like normal, except you keep getting responses again and again as it changes. ^.^
That would be trivial to push over websockets as well.
