I currently try find out and make comparison of advantages and disadvantages of two approaches of building and running application on next.js:
Custom Server (currently used approach in my project)
Serverless (approach highly recommended by Next.Js team)
Serverless approach is described as highly recommended approach in Next.js documentation. They also advise to use Vercel, that has build in support for serverless approach in next.js.
My app is using azure cloud for hosting. My app is build and run as custom server approach. I will also use CDN to cache the pages.
Does anyone have experience in implementing next.js in azure infrastructure and CDN with use of:
Custom server approach?
Serverless approach?
Are there any pitfalls i should be aware? Which approach is better with azure and CDN? I saw discussion that Custom server approach may cause problems with caching content on CDN.
Related
I am familiar with svelte.js for client side wherein client and server are disconnected and all communication is via AJAX calls. However, I have a question whether shared hosting without node installation can deploy a sveltekit app?
Any comments are welcome.
Yes and no. You can serve static sveltekit pages generated with #sveltejs/adapter-static. If you want SSR or to use server side load functions, endpoint, or any other 'backend' feature of sveltekit you will need to use a different adapter. For that, you will need #sveltejs/adapter-node, or another adapter. For supported environments see this page of the docs. So yes, you will need a javascript runtime (probably nodejs) to use all of sveltekit's features.
Disclaimer: I do no have extensive SharePoint/.NET experience, mostly read through online Microsoft docs, so asking opinion in this forum.
I am modernizing 2 legacy microsoft apps. One is SharePoint 2013 site used for CMS and other is ASP.NET 2.0 web application having transactional frontend. New combined frontend must be JS based common for all screen sizes. Business wants most cost-effective solution, preferably on-prem. I am bit confused about the approach to unify both. 1) Upgrade path - Put ASP.NET into SharePoint farm and then modernize the UI pages. 2) Rewrite with SharePoint frontend - Build using SharePoint Framework (SPFx) which internally supports modern JS frameworks. 3) Rewrite without SharePoint frontend - Build a common JavaScript UI portal (ReactJS) and access the backend REST APIs (including SharePoint) sitting behind an API Gateway.
For Cost effective solution, don't use spfx / ReactJS. Their development environment settings are costly and expired in sometime by new version sooner.
One can rewrite using jsom in SharePoint online , as SharePoint online provides a very good code editor .
JSOM all operations are below :
https://www.codesharepoint.com/jsom/0/all-methods
Approach 1 (ASP.Net in SP Farm) - I would not consider this 'modernizing' as Microsoft's approach going forward is using front-end javascript based applications, which are extremely powerful with the amount of AD integration/Graph libraries/etc. made available. This feels dated in my eyes and could create issues down the road if the company ever wishes to migrate to SharePoint Online.
Approach 2 (SPFx) - This is where the Microsoft ecosystem is flowing with SharePoint modifications. It's also easy to tie into back-end services or other services using Azure App Registrations. There is a lot of flexibility here, you have the option to use ReactJS as well, among other frameworks. I would recommend this approach
Approach 3 (Custom App) - I have built solutions running off create-react-app and similar frameworks and I still try to leverage SharePoint if it is a significant part of the ecosystem as they have very powerful frameworks for tying into it such as PnPjs. It just makes integration so much easier, and you are working within the context of SharePoint vs a custom application on some other server which must be wary of authentication as well as the potential need of a back-end service for communication to SharePoint.
I want to integrate server monitoring system like DataDog that implements APM standards. I want to achieve this without using the custom server like Express or Koa, just using the out-of-box NextJS server. My NextJS server is only being used for pages, not APIs. It would help if NextJS allows us to insert middleware for all requests. However it doesn't look like that's an option. Do you know a good way to do this?
Currently we use ASP.NET core project for our UI. There is need to add an OData service to it. As far as I understand it is not supported well enough yet, so it was decided to implement it in a separate Web.Api 2 project.
Is there someone who has such an experience?
Is it a way to go?
May I encounter troubles with deployment to Azure?
Any ideas and thoughts would be appreciated.
If you hosted the web site on a different web application, then you have to enable CORS on the web API, and you have to test it during development to avoid any issues.
You can overcome this issue by deploying both the UI and API to the same Azure Web App. you can have the UI under the root and the API under a virtual directory, ex: apis
I have recently started using Azure CDN for a web app hosted on Azure under the "Standard" Service plan. CDn was working great and page loads dramatically decreased. For some reasons, I needed to shift the web app from Azure to a shared hosting provider and I notice that CDN is not helping much with the page speed as it used to do when the web app was hosted on Azure. Are there any changes that need to be made to make Azure CDN work with shared hosting provider?
Have you tried testing with a different CDN provider to see if you still experience the same slow speeds while using shared hosting? This could help further narrow down the issue of wether it is CDN or origin server related.
KeyCDN for example offers a variety of integration options that may be of interest.
We would need to know much more about the characteristics and examples of the performance decrease that you are seeing to be able to provide directed feedback. Overall the network paths between the CDN POPS and the Azure data centers are optimized so it is possible that by switching to an origin outside of Azure you are losing this optimization. This could be most noticeable if you have a lot of long tail content that requires the CDN to make frequent requests to your origin to fill CDN POP's caches. Once the content is cached on the CDN you shouldn't expect to see a difference in performance. You can use the load capability from the Azure Portal or CDN API's to instruct the CDN to load content on the CDN POP's prior to client requests to help isolate if this is an origin issue or not.
Load Rest API: https://msdn.microsoft.com/en-us/library/azure/mt634451.aspx
c# SDK for Load: https://github.com/Azure/azure-sdk-for-net/blob/AutoRest/src/ResourceManagement/Cdn/Microsoft.Azure.Management.Cdn/Generated/EndpointsOperations.cs#L1689
You can setup C# sdk using nuget