I don’t find GQL to be too much overhead. Plus, I think it’s more than worth it. I’ve lost count on how many “REST” APIs I’ve seen that couldn’t even follow basic collection/resource noun conventions and odd ways of handling authentication (basic, query params, x-something, Bearer, etc). Also, it’s essentially self-documenting via introspection, and you never have to worry about sending too little or bloating the response, or dealing with Swagger / OpenAPI / Postman collections. I usually pair it with Guardian, with a set of plugs that handle the initial header / JWT / resource / blacklist logic. I think the biggest concern is that you could accidentally allow someone to backdoor their way to sensitive information through a maze of querying. Something to watch out for, I suppose. Apollo has been doing some really interesting things with caching and tracing as well.
I initially offered both REST and GraphQL simultaneously, with the REST API sitting on top of the GraphQL layer. So a REST call for /users/1 would internally call a GQL query, which would then tap into Ecto. GraphQL acts as the “view” for your REST API; which allows your REST logic to be quite thin. It’s not really too much trouble to offer both if your REST API is built on top of your GraphQL API.
Yes, I use vuex. I’m always looking for better ways to do it, but I almost always interact with any API (whether it’s Apollo, Axios, etc.) via the Vuex store actions. That piece is relatively constant. The piece that I go back and forth on, is whether or not to store the state in Vuex or within the components and let the data cascade.
In the former, the stores are loosely tied to a URL struture. So I might have a store called product which has a get action. When someone navigates to the /products/1 page, the get action is called and populates the state with that product’s data. The components within the page tend to make use of mapState and computed properties quite a bit. When the user navigates away, the page component is responsible for “resetting” the store’s state (usually on beforeDestroy).
In the latter, I treat the store like an Elixir module, and essentially ignore the state functionality. The stores are not tied to URLs, and since there is no state, you don’t have to worry about resetting it. So I might have a product store, with get, all, update, actions. They don’t commit, they simply return the data. Whatever component made the API call is responsible for passing the data down to the child components; which I presume makes fans of dependency injection warm and fuzzy. In that model, you could make the argument that you don’t even need Vuex anymore, but I’d disagree because I still use the root store for session data. I also find that I have way more props on components than I’d like, and sometimes they’re there just as a pass-through to a child component! The elder components end up passing the kitchen sink down just incase a great-great-great grandchild component might need it.
In my opinion, they both have their merits, and I honestly go back and forth between which I prefer. I think Evan would say the latter was for smaller apps, and the former was for bigger apps. There’s a lot of gray area in there though…
Hope that helps.
