Camarero is a ready-to-use solution to add some JSON API functionality to the existing application or to implement the read-only JSON API from the scratch when more sophisticated (read: heavy) solutions are not desirable. Below is the typical picture of how Camarero is supposed to be plugged in.
It is blazingly fast.
Blogpost with details: https://dev.to/mudasobwa/plug-in-json-api-readonly-webserver-17b4
Hexdocs: https://hexdocs.pm/camarero/Camarero.Catering.html#content
5 Likes
Very neat. We use JSONAPI at work and have a familiar yet different solution! Going to look around the code and see if we can borrow any of the ideas.
2 Likes
Feel free to ask questions if any. The main advantage is statically generated routes and an ability to expose literally any existing storage implementing an Access
behaviour.
1 Like
We do dynamic route lookup by matching on the path and finding a resource that has a route corresponding to that name, to get around the static route generation problem. On a sufficiently large resource graph you get thousands and thousands of routes, whereas in our solution you get the 10 or so JSON API routes for GET, PUT, POST, DELETE + the relationship analogs which makes looking at the route definitions more reasonable.
I like the idea of the Access behaviour though, I have to think if that would clean up anything on our end!
1 Like
Even after reading your blog post I still cannot understand what exactly is this library about.
Can you give a more detailed example to demonstrate its strengths? Say you have an app that is mostly server-side rendering Phoenix modules and the team is looking for a cheap way to expose those as a read-only JSON API. Can Camarero help with that? And how exactly?
Maybe I am stupid for not getting it.
It’s read-write since v0.4.0
btw
Well, if there is already Phoenix I honestly do not see any reason to use the library. It’s more about microservices.
You might think about it as about cheap inplace KV-store. In our ecosystem many microservices expose some data. The data is being updated by some internal business rules. At any time it might be queried—here Camarero rocks.
Imagine Redis that might execute code on it’s own—this would be another analogue.
Example from real life: we collect currency rates from many different sources, make some internal computations (check the validness, cross-compute those not exposed by our providers etc.) Camarero serves the up-to-date rates for currency pairs. It’s faster, easier and to some extent more reliable than Redis. The main advantage is we were able to plug it into existing microservice in literally 10 minutes: one simply adds use Camarero
to the existing Agent
—and voilà. Or, safer and generally better, produces 3 LoCs module that wraps the existing Agent
.
So it’s adding a JSON layer on top of a very minimal app that doesn’t use higher-level libraries like Phoenix or Absinthe? And it’s more like JSON-API-enabling a K/V store shaped data inside the said minimal app?
If so, your title here is confusing.
True, save for the app is not required to be minimal by any mean. Not everything in the world deals with user in any way. There are huge applications running on their own and serving billions of requests. They do not need Phoenix ( I doubt I understand how Absinth is ever connected here.)
I will think about how to make the title less confusing.