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!
I know Next.js is front-end but when i used API of next.js it can response and can manage route or anything about back-end can do.
Then i want to know "Next.js api is back-end ?"
Yes. Next.js is a pre-rendered React app in the client-side that users can view and interact with and can be considered as front-end. At the same time, it also does server-side rendering and API routes which can perform server-side code and access data in the database and can be considered as back-end.
Next.js > v13 uses two folders app or api for Dynamic Routing. Store React components in app for client-side or server rendered components. The backend functions or server-side of Next.js is with the api folder. The api JavaScript code is not executed in the browser but with Node.js so this is not safe for static page generation. When Next.js is hosted in the cloud with Vercel then your server-side or serverless JS will render, but on Netlify or other static hosts the api folder will be ignored or throw errors. It's like running Express.js code in the browser the JIT rendered will fail
Next.js v13 transitioned React folders from pages to app and currently supports both folders. Before v13 the React client code was stored in pages only.
Next.js api provides REST API. We are sending requests internally to our next.api routes. With this you can add business logic in your next.js project without writing any additional custom server code and without configuring any api routes. In node.js app, we need to separete api code into controllers and routes, then register each route in express app, then you need to make sure that you registered the routes in correct order.
The only drawback as of now, vercel does not support websocket connections. So you cannot have realtime services. But you can kinda make it almost realtime with SWR. More on SWR Basically, with swr, you tell next.js to fetch data periodically, keep the response in cache and serve it.
With this feature, Next.js provides everything to build a full-stack application. So next.js also simplifies the backend for us.
Yes. Next js is framework of React js. you can use it both like- frontend and backend. Thanks.
I come from the asp.net world and am slowly, enjoying, learning javascript development. It does clash with me though when people describe something like Next.js, which I'm enjoying learning, as a backend.
To me it is more conceptually like an asp.net server-side frontend (Webforms, MVC, Razor Pages) etc. It seems its main concern is producing reactive frontend UI. Just because some of the frontend functionality runs/processed on server does NOT make it a backend AT ALL.
What about the fact it has api endpoints?
Well to me, a web api is only a means of enabling a frontend to talk to a backend across a network, the internet in this case. For me an api handles only very limited concerns; provides the endpoints, handles de/serialisation, talks http to the caller and that's kind of it, thin and dumb.
The backend doesn't really start till you get to your App layer and then the architectural fun can start, Application orchestration, Domain logic, dependency inverted data access layer etc. etc. all the things that talk to the complexity of designing robust software.
So much talk seems to be focused on where bits sit, is it on the client, is it on the server and less about the concern of what goes where.
I thing Next.js is an excellent server-side, frontend framework but whatever your onward stack into the backend, it's not a backend!
Your Question: "Then i want to know "Next.js api is back-end ?""
Simple Answer: It depends
For any technology to be a backend it must fulfill its minimum criteria to identify itself as a backend.
If you don't use NextJS features and use it as a frontend, it behaves as a frontend.
But you can use it as a backend if you want to use that way.
I'm architecting a public web API for my service. It will be equally consumed by web pages and native mobile apps (iOS, Android and Windows 8).
Should I use cookie-based authentication? I mean, is this the best practice for this scenario?
Futher Info:
After a little research in the authentication/authorization/openId-connect field i realized that most of everything is handled by the browser, by that i mean, the redirects, coockie insertion and related "boiler-plate" stuff... when i think about all that boiler-plate that i will have to duplicate in my natives apps, i wonder if that model is the best for mobile apps. i mean, maybe theres another more mobile-native-friendly way...
Ps: i know that this is a little generic still, it's just that i'm a begginer in the field of security and i dont know how to properly express my doubts/concerns/"laziness" still...
The API itself should really be stateless, and not manage any sessions. Each request to an API should be made with the authentication details (e.g. OAuth token).
If the Web pages and mobile applications need to maintain some kind of session, then it should be up to them as clients of the service to maintain that state. For instance, a Web page might set a session cookie for the user, but a native mobile app might want a completely different approach.
See also: If REST applications are supposed to be stateless, how do you manage sessions?
I need some help with securing a single page multi-tenant saas application.
Questions:
1) What is the best way to implement it? I am trying the build the application using angularjs, spring mvc and REST.
2) Can this be done using Spring Security? Any example with creating login page and securing REST, calls will be helpful?
I have found a sample for implementing spring security with Spring JPA (http://krams915.blogspot.com/2012/01/spring-security-31-implement_3065.html) but it is not for SPA and SaaS.
I understand this a very broad question but i am new to SPA, REST and SaaS so any pointers will be helpful.
Thanks...
I have already participated in two projects with SPA and security aspects. Last of them was GWT + Spring Security. I am sure that you can use successfully Angular and Spring Security together.
Unfortunately there is no built-in config parameter 'we are in SPA mode' in Spring Security AFAIK. So some tweaking / conf from Spring Security side will be necessary. Example:
imagine that during login you call built-in into Spring Security login controller. In a case of successfull authentication by default user will be redirected to index page, where in a case of failure it will be redirected to corresponding error page. It is a normal behavior for standard web applications that will be not so useful for SPA web applications. In a case of SPA you need to detect AJAX call and print JSON with username / roles for successfull cases or send 401 code for failures (then detect 401 in JS and show corresponding error). You can use corresponding extention points from Spring Security to do so: AuthenticationSuccessHandler and AuthenticationFailureHandler.
Some another thing to tweak: by default after session expiration user will be redirected to login page (and SPA app receive login page as a response to the next AJAX call).
Looking into my personal exprience general guide will be like so: after login load list of roles into JS. Use it to show / hide corresponding components on UI side. Apply the same list of restrictions on server side too. To make sure that user do not edit JS in browser (although in a case of minified JS of some medium size app it will very complex task). On the server side you must choose between:
Secure URLs of AJAX calls
Secure some Java methods.
I prefer second one (secure business methods on services). I think it is more convinient because normally we want secure business operations, not some endpoints. As adwantage you will be able expose your business logic via some other protocol, and security will be there already. From other side I can imagine some business requirement to have different permissions for different endpoints / protocols. So it depends more on your actual situation.
Lage size JS applications must be splitted into modules. To decrease direct dependencies it may be better to use events insted of direct calls to cummunicate between modules. There are interesting thoughts of Addy Osmany about how to do security in these coditions. I did not found good link to it, maybe this or this will be helpfull (search "permission").
Feel free to post any questions. Good luck.
I have built a cakephp site with RESTFul calls. Happy to say these calls work when using curl from another php site. (This is all testing at the moment)
The next stage is setting up authorization, from my understand I'd be looking at either basic or digest loging to make RESTful calls.
I'd like to build a phonegap app, that requires login. Would RESTful calls to CakePHP be the way to go. i.e making a RESTful API for my site?
I'd like to provide an API key. How would this key be secured in a phonegap app?
How secure is phonegap in general? If the files for an app are css, html, js can't the app be broken into and the files revealed
Just looking for general advice and a direction to continue researching.
I believe what you need would be a stateless authentication system. CakePHP comes with 2 built in. Take a look at this example