How can we create an endpoint using Sanity CMS which lets us execute custom server-side code? e.g. https://my-sanity-cms.com/api/my-endpoint
Within NextJS we can create /pages/api/endpoint.js and we can then access .com/api/endpoint via any http clients.
We want to be able to do this as our CMS needs to talk to some 3rd party systems and execute some server-side code, so ideally we can make an endpoint we can use?
Thanks
you can just set that up with NextJS and have it do whatever it needs to do using the Sanity APIs to read/write content inside Sanity and the 3rd party APIs to do whatever they need to do. You can then deploy that with Vercel or similar and use that endpoint from inside the studio.
There is however no way to run custom code inside the Sanity backend service, but lots of companies deploy separate projects in order to integrate data across systems.
Related
I want to create web app in Nextjs and in the future mobile app in React Native. But I am confused what api to use. Do you think that the Nextjs api can handle both web and mobile apps? Is this possible and is it good idea at all? Should I use PHP backend for that? Thank you very much.
With the assumption that you are talking about API Routes :
I would ask you that you think through the scale of your web and app. If this is a simple web/app that you do not expect to grow much - The NextJS API which is similar to standing up an nodejs express server is not a bad option.
Remember a few considerations when designing this API
You may have to distinguish the request origin (web/app)
CORS may have to be customized - Next exposes this
You could set an app specific route to ensure isolation or use headers to distinguish behavior if your application bifurcates in the future.
These concerns are shared even if you made a PHP, ExpresJS or any other API middleware.
Once you are past all this, i would ask you to consider
Using a GraphQL server like Apollo that works nicely with Next and is custom built for this purpose..
Evaluating API Gateways for security and scale.
You don't use any external tools at all.
Next JS has serverless model. So, you don't need to mess with BE.
You can create a number of API routes you want. in /pages/api folder. You can even split like /pages/api/desktop and
/pages/api/mobile folders.
You connect your database (MongDB, sql etc) via /middleware/your_file.js. Here is example for MongoDB
If you like, you can even add some security (ex: Auth0, next-auth
etc) to secure your API routes created in /pages/api folder. Example for Auth0
After, you can access you data througth API calls. Very good!
Is there any solution to automatically generate a web UI from a REST API?
I found Swagger codegen but it generates a client for the API, not a UI.
I need a basic UI, allowing directly from the browser to use the different endpoints and display the response prettily. Something like a basic Postman that would be directly integrated into my website.
I don't have constraint about how the generation is done. Can be done once at build time, or at runtime on server side or on client side.
I've heard good things about retool.com, it seems to do what you need.
I have created some APIs in API management layer, which are essentially proxies between the calling client and an underlying web api.
I did this by importing the swagger file of the underlying API, and then adding the newly created API to a Product, repeating this for each separate proxy that I needed. This means then that the underlying API could be called but not without the subscriber key of the product that the newly created API was attached to.
Is it possible to do something similar with API apps, i.e. creating API apps using just the swagger file from the underlying API in the azure portal, that act as proxies between the calling client and an underlying web api (as below)?
Do you mind expanding on why do you need to have API Apps acting as proxies?
I am not aware of such capability for API Apps specifically. There are Swagger-based code generation tools available, for example on http://swagger.io/open-source-integrations/. So perhaps you will be able to find something that would work for you.
We are developing a custom console to manage development environments. We have several application templates preloaded in openshift, and whenever a developer wants to create a new environment, we would need to tell openshift (via REST API) to create a new application based on one of those templates (oc new-app template).
I can't find anything in the REST API specification. Is there any alternative way to do this?
Thanks
There is no single API that today creates all of that in one go. The reason is that the create flow is intended to span multiple disjoint API servers (today, Kube and OpenShift resources can be created at once, and in the future, individual Kube extensions). We wanted to preserve the possibility that a client was authenticated to each individual API group. However, it makes it harder to write easy clients like this, so it is something we plan on adding.
Today the flow from the CLI and WebUI is:
Fetch the template
Invoke the POST /processedtemplates endpoint
For each "object" returned invoke the right create call.
I have a web application (typical mvc webapp) that needs to call a REST API bundled in a different webapp (war file).
The first web app serves as a front to the separate REST API webapp for customers to register and view their stats, purchase plans etc. But part of the design of this webapp is that it must have example invocations to the other REST API webapp.
There are many rest clients out there, but what would be a reasonable approach to address the above?
I was thinking of using the Spring REST Template to call the REST API but from my mvc controller class in the first webapp. Is this a reasonable approach?
Once you deploy a webapp using your deployment tool of choice, you can simply call the REST URL. That's one of the great things about REST - it doesn't care about what sort of tool is calling it because it deals in a neutral medium (usually HTTP). Twitter's REST API (here) doesn't care what's calling it - in fact the beauty of it is that anyone can make an app that calls it.
So say you deployed a webapp locally to port 8080, you can just make a REST call to http://localhost:8080/firstapp/rest/foo.
If you're deployed to the World Wide Web, then just call the appropriate domain.
Yes, RestTemplate is a very convenient way for server to server REST calls. Though there are some tricks if you are going to serialize generics.