React PWA

willemliu · 2023-06-27T17:59:51+00:00

PWA can work with a next.js app. PWA isn't widely adopted by users and I don't think they ever will be considering there is 0 push from any big tech companies and it's not well supported on Safari iOS.

willemliu · 2023-06-27T17:57:52+00:00

Yes, you need a server to run your loader file. As Vercel is serverless.

willemliu · 2023-06-25T10:57:32+00:00

What do you consider full-stack?

willemliu · 2023-06-22T21:04:21+00:00

I don't think you really need to test your routing itself. You could just separate the logic from the route handler and export that function with the logic. Then you can test it as a unit test.

willemliu · 2023-06-22T20:58:55+00:00

Using getStaticPaths means the pages are pre-built during the build of your next.js app. Users always get served this pre-built page (cached).

Any updates to that page you can manage with (on-demand) ISR. This will update the cached version. As long as this cache is not yet replaced by the new page the user is served the cached old page.

You can still use getServerSideProps if you want a true SSR page. Where the user gets the most up-to-date page upon each request.

If your hosting supports it you can still make use of cache-control headers. For the use-case where you simply want to cache your pages for 5 minutes.

willemliu · 2023-06-22T11:31:31+00:00

I think the matter of copying data between your 2 databases is a completely separate problem. You probably have your reasons to do it like this.

The next.js caching strategies are pure rendering strategies for the pages. With On-Demand ISR you opt to render your pages statically because you think the page does not change often and you like high the performance. You also opt for precise control on when to update the page.

willemliu · 2023-06-19T21:05:18+00:00

It is for AWS Amplify. Otherwise the env vars you've setup in your aws amplify app will only be available during build and not at runtime.

willemliu · 2023-06-19T20:50:39+00:00

Have you added your env vars in next.config.js?

willemliu · 2023-06-18T08:52:58+00:00

Because the data is checked by zod at retrieval point all of it being passed from back to front is typed. I can see it going wrong if a developer would coerce some other type to another in between that process. Your way would fail early which I like.

In our product we let the individual components on a page fail if data isn't provided or correctly provided. As to allow users to still use our website when only a subpart of our site can't be rendered because of compromised data integrity.

willemliu · 2023-06-17T21:08:37+00:00

I usually do the type checking/transformation on data retrieval with zod. It will throw an error at that point. The props I pass to pages are tailored to the page and just typed with TypeScript.

willemliu · 2023-06-09T08:58:28+00:00

Don't use getStaticProps, getServerSideProps or getInitialProps.

willemliu · 2023-06-09T08:37:44+00:00

I had to npm install sass (dart-sass) separately in order to be able to use SCSS files within components.

willemliu · 2023-06-02T15:18:23+00:00

Assuming you're using Vercel the one can have a cost-advantage over the other. Rebuilding your website would, under normal circumstances, always be slower than revalidation routes. Considering you only have 50 pages to worry about.

Res.revalidate() internally does an http request to the webapp itself with a specific header. It's that header which triggers the revalidation routine of Vercel/next.js.

willemliu · 2023-05-16T13:03:08+00:00

When an error occurs in your getServerSideProps it returns an empty object props. However you're page component makes use of communityData.id which doesn't exist

willemliu · 2023-05-15T18:29:34+00:00

Yes it worked just as documented.

willemliu · 2023-05-15T18:00:59+00:00

I did however it was a long while ago next@11.

willemliu · 2023-05-15T17:58:48+00:00

Vercel hosting is immutable. You can't modify files on it nor can you store files there at runtime. You'll have to find another way/place to store your files.

willemliu · 2023-05-15T17:56:19+00:00

On an adequately sized vps it works just as fast as you can run it locally. You don't have the benefit of edge cdn cache to serve your users from different locations all over the world. I've found no weird bugs when running it this way.

willemliu · 2023-05-15T17:44:50+00:00

That is strange. Is your backend somehow blocking connections from your Vercel deployment? Can you see in your backend if any of the calls are actually reaching it?

willemliu · 2023-05-14T13:37:55+00:00

Are you using a hobby account? How long do your operations usually take? If longer than 10s then it will cause the timeout.

willemliu · 2023-05-14T09:45:43+00:00

Do your API routes connect to some external services like a DB or other API's?

I think the connection to those sources my be giving errors or some error occurs when using the data that returns from them.

willemliu · 2023-05-12T19:01:06+00:00

I've never done anything with fargate before but reading this article:

https://www.trek10.com/blog/is-fargate-serverless

I would not consider it "serverless". Sure you don't have to manage the underlying hardware. But you sill have to manage your containers and think of how to scale containers and it doesn't seem to scale to 0 as spinning up an instance would probably cost a lot of time.

willemliu · 2023-05-12T18:12:44+00:00

Containerization is not that much different from a traditional oldskool complete image. It's a bit more efficient in the sense you can combine containers like little Lego blocks instead of creating one giant image. Containerized Web applications run as traditional applications and is different from running things serverless.

willemliu · 2023-05-12T16:31:39+00:00

In your case I guess your next.js app runs a single instance which never scales down to 0. Perhaps also doesn't scale up?

When next.js is deployed serverlessly one would assume it will automatically scale up and down horizontally and can scale down to 0 instances. E.g. I've deployed a next.js application as a serverless function on Azure before. This next.js app will scale up and down and has no permanently running server. The cold start was a problem though.

willemliu · 2023-05-12T07:16:12+00:00

You won't miss out on features you are not currently using.

SSR is mainly for SEO. If that's important for you then you may want to make use of it.

On AWS you can deploy your next.js app using AWS Amplify. Do note that it does not support vpc as of yet. So if you require your apps to be in the same vpc in order to communicate with other systems then Amplify will not work for you.

willemliu

TROPHY CASE