Migrate to Azure Static Web Apps

[tobiasdiez]

Blocked by Azure/static-web-apps#623 (as nuxt requires at least node 14)

https://azure.microsoft.com/en-us/pricing/details/app-service/static/

TODO:

• Migrate server to https://www.npmjs.com/package/apollo-server-azure-functions (https://docs.microsoft.com/en-us/azure/developer/javascript/how-to/with-web-app/graphql/azure-function-hello-world) or use feat: add @vue/apollo example implementation nuxt/framework#70?
• Generate most routes during build (requires https://github.com/nuxt/framework/discussions/560)
• Migrate deploy envs: https://docs.microsoft.com/en-us/azure/static-web-apps/named-environments?tabs=github-actions
• Setup dev environment https://docs.microsoft.com/en-us/azure/static-web-apps/local-development
• Migration https://v3.nuxtjs.org/docs/deployment/azure
• PR preview https://docs.microsoft.com/en-us/azure/static-web-apps/review-publish-pull-requests
• Require "Build and Deploy Job" to pass before merge of PR

[mohit038-zz]

I don’t think azure-static-web-apps are for apps that require server-side rendering.

Static web apps are commonly built using libraries and frameworks like Angular, React, Svelte, Vue, or Blazor where server side rendering is not required. These apps include HTML, CSS, JavaScript, and image assets that make up the application. With a traditional web server, these assets are served from a single server alongside any required API endpoints.
https://docs.microsoft.com/en-us/azure/static-web-apps/overview

I have a few questions about why we need server-side rendering for this project.

Usually, client-side rendering is preferred for a dashboard-type project where everything is locked behind the login screen.

Cons of client-side rendering (SPA):

• SEO is not good. But we don’t want anything behind the login screen to be indexed by any search engine.

• The site will not work if you turn off javascript in your browser. But this is not a big deal. In mostly every browser, js is enabled by default.

• Initial loading time is larger than a server-side rendered app as we have to fetch all of the javascript at once. But this can be solved by lazy-loading the components.

Pros:

• User experience is really good in client-side rendered apps. The whole tab will not reload if you navigate to a different route.
• A web server is not required to render the app. (generally cheaper to host)

Generally, SEO is an issue for a client-side rendered app(SPA) if you want multiple pages to be indexed by a search engine. Client-Side apps are single-page apps. We just dynamically change the body of the page when we change the route and everything else remains the same on every route, and Seach engine crowlers rely on <meta/> tags inside the <head/>. So, in conclusion, the whole app is just a single page for a search engine crawler.

Why should we consider client-side rendering(SPA):

• If I understand correctly, we just need a dashboard where users can manage their citations. Then, I would highly suggest using a single-page application.

server-side rendering:

• If we need an explore page where users can read articles, do their research, etc. Then we should index this page.
• Or If we want to add a public user profile page like the GitHub (www.github.com/mohit038) where users can show their work, Add their university, designation, etc. Then also, server-side rendering would be helpful.

In conclusion, server-side rendering is unnecessary if we just need a dashboard. SEO on jabref landing page is really good. We can directly connect jabref-online from www.jabref.org/admin or /dashboard. I guess vue-cli can create the boilerplate code for a SPA, and we can get rid of nuxt(Whenever I try to spin a local development server, it rarely works for me. I get so many errors. Please clone this repo again and try to run the server.). Or maybe please reconsider React. React has excellent community support (There is a library for everything in react), and every framework (next, create-react-app) for React works seamlessly. Plus, typescript support in react is amazing. Plus, you can share the business logic if you plan to create an app for ios and android with react native in the future. Plz, reconsider React.

[tobiasdiez]

Thanks for your input. I agree with almost everything!

For the dashboard feature, client side rendering is indeed all we need. But I also plan to integrate the main jabref website, as well as the blog to have everything in one place and with the same design. Also in the future we might indeed add user profiles and/or pages where you can view research articles (similar to researchgate). For these things ssr (or even build-time rendering) makes sense. But yes, for now we can disable ssr. It's exactly this hybrid design were things like nuxt can support us, because there you can declare certain routes to be spa, others ssr and others build-time rendering.

Azure static does support ssr through azure functions, and this is something nuxt automatically takes care of.

Finally, yes, the current setup is a mess and doesn't work half of the time. I shouldn't have upgraded to nuxt-bridge which is not really production ready. Things are way better with nuxt3 which runs now relatively stable (with some hickups due to esm packages, but this is generally okay and only gives headaches upon package upgrades). I hope I can merge #1009 in the coming days.
If you have a bit of time and want to contribute, adding storybook stories for the other components would be helpful. This would give us confidence that package upgrades (in particular nuxt3) don't break anything important. And it doesn't require to spin-up the nuxt server, just run yarn storybook. Example: https://github.com/JabRef/JabRefOnline/blob/main/components/t-input.stories.ts, and here is the list of all tailwind components: https://github.com/JabRef/JabRefOnline/blob/main/plugins/tailwind.ts

Thanks for your continued interest. It's been a busy time for me the past few months, but hopefully I find more time in the near future to develop on jabref online so that we can finally show the world your nice work on the word plugin. We should also have a call soon again!

[mohit038-zz]

If you have a bit of time and want to contribute, adding storybook stories for the other components would be helpful.

Ok

We should also have a call soon again!

Sure, Let me know when you're free.