Hi all,
we’re planning to build external frontend CRM and use Corteza as backend
I know corteza has rest API, but the API is a bit generic. some of the frontend pages need many things from Corteza … things like
- read record fields
- read related record fields
- read one or two fields of the record
- aggregate some fields in a module
- trigger some of the automation (workflow/scripts)
I know all of these are supported by Corteza by default but my concern here is if all the above are on one page, the frontend team would do many HTTP requests for each one!
so, I’m looking for your input and the best approach solution for using Corteza as a headless CRM
I don’t think you need to worry about the number of requests unless there will be hundreds of them per page. What I’d do is write a little SDK (like we’ve done here so that your front-end team can use simple one-line calls and the underlying implementation can change once we expand the API for more flexibility (we were discussing implementing some other API’s like GraphQL but we didn’t get to any conclusions yet).
You could consider sink endpoints, integration gateway, and even explicit automation (it’s invoked with an HTTP call) to define custom endpoints for the larger operations (careful with authentication for the first two)
What we’ve done a few years back (before we reworked authentication and access control) is that we’ve set up a Vue.js front-end and a simple NodeJS back-end. The back-end would then proxy “simple” requests from the front end over to (multiple) Corteza endpoints.
We did it like so because we needed some extra flexibility and credential work on the back-end side.
@tjerman thanks man
regarding your first input can you please elaborate more?
also, if I want to create a custom API I would use an integration gateway and link it with an automation script … how would I use the same authentication method generic API ?
I’m interested if there real example on how to do it
Not sure what more I can add here, so if you could come forth with questions that would be best.
Aggregate all (or more complex) operations your custom front-end would do, write a single function for each one of them, and then use them in your webapp.
Let me break it down a bit…
Integration gateway’s initial requirement/implementation was to handle webhooks and asynchronous requests, so there (currently) isn’t much flexibility in formatting responses (for GET /ap/some/data as an example). Extensions are planned to be added but I don’t have a timeline for that. Authentication is not covered by the built-in auth system.
Sink routes are more flexible and allow you to set nearly anything as far as the HTTP response goes (headers, content, …).
The problem you’d have with sink routes is that you need to provide a sink signature in order for the request to be considered as authorized.
If you’ll only be building a web application (just the front-end) this won’t be ok for you. If you’ll be building a front-end with an intermediate API (like I’ve mentioned in my first reply), then you can use them (just make sure the signatures are hidden on the back-end).
Explicit automation can be invoked via REST API, they are protected by the built-in authentication (those JWT tokens and such).
They also allow you to set some response data so they could be used as custom API endpoints but you’d need to experiment with them a bit.
The last time I used them like so was in 2021.9 (I think) with server automation scripts.
Conclusion
I would suggest you start off with the SDK suggestion. We can discuss custom endpoints when/if we get to that point.