KAJAN M

Reflection on ASP.NET Core, Vue multi page application project setup

February 04, 2021

vueasp-net-corewebpackmulti-page-applicationpersonal-reflection

Table of Contents

Introduction

In our company, we’ve been using a different ASP.NET Core MVC, Vue project setup.

It’s a multi-page application(MPA), where its each page can act like a SPA on its own.

Our intention was not to make each page a SPA, I said just because it’s a possibility.

All we wanted was to build user interfaces using Vue while getting the most out of that the ASP.NET Core MVC already provides, like routing, authentication, and access control.

Having contributed to the project setup and worked on two similar projects, I want to reflect on the pros, cons, and possible improvements in this approach.

My first experience with ASP. NET Core, Vue MPA

Two years before, I was tasked to set up Webpack to summits.com project. At that time, I was the only main developer.

The project was already set up as an ASP.NET Core MVC application. The project had Angular JS 1, jQuery as drop-in dependencies. Initially, I was assigned to refactor to replace those dependencies with Vue. I started using Vue as a drop-in dependency, loaded using CDN. Basically, I wrote the template(HTML) in razor views and component logic(computed, methods, etc.) in IIFEs. All styles were managed in a global CSS file without built-in minification, post CSS setup 😐.

Later, as time passed, we realized the need for a build system. Being a beginner developer, only having gone through some ASP.NET Core, Vue Pluralsight, Udemy courses, I found the task very challenging. In-fact almost all of the tutorials that I’ve gone through discussed ASP.NET Core as either Razor/MVC MPA or web API with a Vue/Angular/React SPA.

However, with some awesome Webpack courses from Pluralsight, Front End Masters 🙏, I managed to come up with a working setup 💪. In that setup, the majority of the content was rendered on the server-side using Razor. We used Vue for only components that needed reactivity. We didn’t have many reactive components in that project, also SEO is a key project requirement, so rendering most of the content on the server-side was a must. If I’m asked now, I would suggest using Gatsby instead, anyway, this was my first experience with an ASP.NET Core, Vue MPA setup.

My second experience with ASP.NET Core, Vue MPA

Six months later, I was assigned to a new project and asked to come up with a similar project setup. But this time SEO is not a concern at all. Considering the complexities in setting up the project I pinged our Technical Lead in chat asking why not a SPA.

Anna, MPA architecture is confirmed, right?
  1. Majority of the content will be server-side rendered
  2. Vue will be used mainly for the components that need user interactivity
  3. The data required for the Vue components will be passed through Js variables
  4. AJAX requests are avoided as much as possible

Following things make me think why not a SPA
  1. Vue has more reusable UI components.
  2. Anyway, we’ll need to write API controllers and make AJAX requests.
  3. SEO is not needed for this project.
  4. Now there are 3 devs, FE, BE can separately evolve
  5. There might be a mobile app in phase-2, can reuse the API controllers

Since I haven't worked with any enterprise-grade SPA before I decided not to question the instructions.

This morning, I received a screencast from my friend, it’s a SPA, an Angular FE talking to .NET Core API. My friend did this for an interview task and asked to do within one day. My friend is making use of Angular Material components. After seeing the demo I’m seriously thinking why not leave the FE to just Vue.

Want to check if you decided to go for MPA thinking SPA is too complex for the developer. If so plz let me know, I am compatible working in both Vue and ASP.NET Core (Definitely, I’ll need your guidance but I’ll use the opportunity wisely and will not disturb you unnecessarily).

Here is our technical lead’s reply.

Good points. This is of some concern to us as well. In short the rationale is that SPAs while in theory meet our expectation, in practice are hard to implement, become very bloated and provide sub standard user experience. Developers make fewer mistakes and are able to accomplish things faster when they are trying to reason the solution in terms of data displayed page by page versus managing data in an application. Real optimizations of website speed almost always are at the server side (unless you have a poorly written frontend).

This doesn’t mean SPA is generally a bad idea, SPAs are great for a desktop replacement application or websites that supply a continuous stream of data (think Gmail, Facebook or Twitter). But for Web applications MPAs fit the requirements better (think Amazon, Reddit, LinkedIn, Stackoverflow, Github, Bitbucket or Jira).

Javascript in my opinion should only be used to provide dynamism to styled markup. It is possible to make a lean SPA but it needs discipline. Oftentimes we find developers getting lost in doing things the react way or vue way and miss the objective of creating the website in the first place - provide a snappy ui for users to manipulate and view their data. Means very often become ends in themselves. This is suboptimal for both the developers and users.

While we are developing this application we need to keep a few things in mind

  1. Show users what they want as soon as possible
  2. Fetch as little data as possible from the server
  3. Make the least amount of queries against the database to accomplish your goal
  4. Minimize UI gimmicks

From your (a developers) point of view, I believe you are much better off possessing a skillset that enables you to make a fast and well-performing website than flavour of the month SPA technology.

To address your point about mobile applications and future enhancements, it’s generally a bad idea to engineer for stuff that you think may happen in the future. Almost certainly, the users will want significant changes to the web app after they start using it. Let’s figure things out in the here and now while keeping ourselves flexible to extend versus actively trying to plan for possible enhancements.

While the reply was convincing, picking SPA + API would be easier kind of feeling often came to me.

Later, we were told that we’ll be using the vue-core-ui-pro component library. So, unlike in the previous setup, this time all UI needs to live in Vue components. Using a component library is helpful for rapid development, and we don’t need SEO for this project, so moving all logic to Vue made sense to me. But still, why not SPA remained a mystery to me.

After two years, having contributed to the project setup and worked in two similar projects, I want to reflect the pros, cons and possible improvements in setting up ASP.NET Core, Vue as an MPA instead of SPA.

Pros

  1. Routing is super simple - we rely on ASP.NET Core’s built-in routing system which works out of the box by convention over configuration.
  2. Authorization/ access-control is super simple - again we rely on ASP.NET Core’s authorization middleware for this
  3. No need to always make API request to get initial data - we can set data to a javascript variable in the returned HTML during server-side rendering
  4. We have an option to render the layout in server side and use Vue only as necessary.
  5. Have more control over SEO.
  6. Want to use Vue in one page and Svelte in another page, no problem, we can do that.

Cons

  1. Setting up the project is not trivial
  2. Less documentation on this approach
  3. As the project grows, webpack-dev-server start time, HMR time increases
  4. Upgrading Webpack can be challenging
  5. Code duplication

Improvements

  1. I haven’t tested this yet, but I think using Parcel/Snowpack would make things easier, I’ll try setting up the project using Parcel and share my experience in a separate post.

Final words

I quite like the ASP.NET Core, Vue MPA approach, and I prefer this approach over SPA for my pet projects as well.

In my next post I’ll share the codes and walk you through the code while answering the whats and whys.

This is my second blog post 🍻. Whenever I think about writing a blog, I doubt about my English skills, I worry if I have a good amount of knowledge on the topic, etc. This feeling often prevents me from writing. Nowadays, I have strictly decided to get along this feeling by writing more content.

Having said that there is a good chance I missed something, or you might have some similar experience to share. Feel free to comment and share your thoughts 😍.