I am learning Cloudinary. It can be integrated with any backend or frontend application using its rich SDK. But it can also be workable with its APIs like https://api.cloudinary.com/v1_1/:cloud_name/:action
with necessary HTTP methods, by directly using the rest API in place of its SDK methods.
But which one is better and why? Any answer is appreciable.
Related
This link https://developers.googleblog.com/2022/03/gis-jsweb-authz-migration.html says
Your full suite of apps and platforms may be using different methods of authentication and authorization from Google. The following are NOT affected by this deprecation announcement:
Android or iOS native app SDKs,
Backend platforms directly calling Google’s OAuth 2.0 or OpenID services.
I'm currently trying to understand our huge legacy code which might be affected by the GIS migration. Currently, we just redirect to https://accounts.google.com/o/oauth2/v2/auth to start the oauth2 process, once the user clicks the "Sign in with google" button. I've seen this link in the example of the old way from the migration document here: https://developers.google.com/identity/oauth2/web/guides/migration-to-gis#oauth-2.0-endpoints however I'm not sure if it is required to migrate to GIS or not.
From what I understand, only the frontend related libraries should be worried, but I'm dumb so maybe I'm misunderstanding. Can anyone help enlighten me?
Thanks.
You do not need to migrate if you are directly making calls to the Google's OAuth 2.0 endpoints.
The guide you reference recommends using the library with the note use the Google Identity Services library to support a less intrusive popup UX mode and to avoid having to manage complex OAuth 2.0 requests and responses. The intent there is to simplify your implementation not to force a migration.
I've just one question, can I make separate server app (backend) with GraphQL API for my Next.JS app (frontend)? I clearly understand technical part of such implementation, but what about supporting Next.JS advantages (for example ability of deploying on Vercel)?
In my opinion, this approach will support all things which available for normal Next.JS app with API Routes (api/graphql), I just make my own API (like very very small GraphCMS), but may be I missed something.
Thanks in advance for all your opinions!
My project uses different protocols to communicate with other services:
REST API
WebSocket (STOMP)
gRPC
own framework build over gRPC.
I need a tool, or a bunch of tools, which allow me to generate documentation for the APIs. In the best scenario, it's a maven plugin that generates a report with all APIs.
We use Swagger to describe the REST API. It has poor export options and needs a lot of annotations in the code, but describes the API well and offer the test machine.
Alternatively, Spring RestDocs (AsciiDoctor) could be used for the REST API describing. It offers a better format for reporting, but we prefer Swagger.
That's all I found for the REST API. But I didn't find anything for describing WebSocket API, gRPC and the custom framework.
I will be very grateful for any help and ideas to solve the problem.
I'm planing on creating an native .net app for Windows as well as a native OSX application with swift.
These two applications should be able to communicate with the same server. With that I mean writing and reading from the same SQL Database, and have REST communication with the server.
Now I'm struggling to come up with a solution for the backend. I'm looking into Serverless backends like Azure or Google Cloud, but I'm not sure that I can use these Services with both my applications. Both Azure and Google Cloud have SDKs for .Net but I've never found one for Swift or Objective-C.
Are there such Services that allow me to communicate or should I just develop my own?
Do you have any good solutions for my problem? Or what is the best server architecture to use for this kind of problem? Any inputs are appreciated!
If your servers vend a REST API, no vendor SDKs should be required. REST is platform- and vendor-agnostic. All you need is an HTTP client, which Swift/ObjC most definitely do have. I use a serverless (AWS Lambda) setup from Swift, and it's easy. Though, I have done this kind of thing before :)
What I would do is setup a simple test server, and expose an API endpoint. Make sure you can reach it with curl from your machine. Then, take a look at the NSURLSession APIs in Foundation. They'll help you make an HTTP request similar to what curl can do. From there, you'll need to investigate serialization (like JSON), which Swift can also do easily (as of Swift 4, I believe).
Good luck!
I read the dropbox ios api documentation and one of the first things that is mentioned is that dropbox api support is for ios 4.2+
I want my app to support older versions of ios as well (3.2 onwards) -
I thought of implementing REST api but i have very little knowledge of OAuth and the rest api in general
I went through googles GTM - OAuth and had a hard time implementing it for dropbox and im not even sure its possible
What i would like to know is that if what is the best approach and what would be appropriate libraries or frameworks i can use to do this in the simplest way possible