SSW Foursquare

Rules to Better Websites - Deployment - 4 Rules

  1. Do you know where to host your Frontend application?

    When building a frontend application for your API, there's a point where the team needs to choose where and how to host the frontend application.Choosing the right hosting option is critical to scalability, available features, and flexibility of the application.

    There are two primary ways to serve your frontend (e.g. Angular) application depending on where the frontend is hosted:

    • Option 1: Integrated with backend

      The frontend is served by the backend API. Both frontend and backend are hosted on the same server. This is usually the easiest way and what the ASP.NET 8 Web Application starter Angular template has.

      Pros & Cons:

      • 🟢 Simple deployment story; backend and frontend will always be in the same version
      • 🟢 Ability to put business logic before serving the frontend
      • 🟢 Ability to serve server-side frontend
      • 🟢 No cross-origin requests
      • ❌ Difficult to scale
      • ❌ Complicated development workflow for multi-team projects
      • ❌ Backend deployment is tied to frontend deployment
    • Option 2: Externally hosted

      The frontend is served standalone on its own separate host. The backend is hosted on a different server.

      Pros & Cons:

      • 🟢 Highly scalable
      • 🟢 Access to CDN
      • 🟢 Reduced backend load
      • 🟢 Flexible technology options - e.g. swapping technology is easier
      • ❌ More complicated deployment
      • ❌ Higher cost

    Based on the pros and cons of each option above, the recommended options are:

    • For small to medium-sized projects with less complicated requirements: Option 1: Integrated with backend is the recommended option since it allows faster development without having to worry too much about infrastructure.
    • For larger projects or projects with complicated requirements: Option 2: Externally hosted is the recommended option since it is more scalable and more flexible with infrastructure or technology changes.
  2. Do you avoid publishing from Visual Studio?

    Publishing from Visual Studio is a convenient way to deploy a web application, but it relies on a single developer’s machine which can lead to problems. Deploying to production should be easily repeatable, and able to be performed from different machines.

    A better way to deploy is by using a defined Build in TFS.

    test publish
    Figure: Bad Example – Using Publish to deploy

    queuing new build
    Figure: Good Example – Queuing a new build to deploy your application

    continuous integration
    Figure: Best example – Use continuous integration to trigger your Continuous Deployment build

  3. Do you use the best deployment tool?

    Often, deployment is either done manually or as part of the build process. But deployment is a completely different step in your lifecycle. It's important that deployment is automated, but done separately from the build process.

    There are two main reasons you should separate your deployment from your build process:

    1. You're not dependent on your servers for your build to succeed. Similarly, if you need to change deployment locations, or add or remove servers, you don't have to edit your build definition and risk breaking your build.
    2. You want to make sure you're deploying the *same* (tested) build of your software to each environment. If your deployment step is part of your build step, you may be rebuilding each time you deploy to a new environment.

    The best tool for deployments is Octopus Deploy.

    Figure: Good Example - SSW uses Octopus Deploy to deploy Sugar Learning

    Octopus Deploy allows you to package your projects in Nuget packages, publish them to the Octopus server, and deploy the package to your configured environments. Advanced users can also perform other tasks as part of a deployment like running integration and smoke tests, or notifying third-party services of a successful deployment.

    Version 2.6 of Octopus Deploy introduced the ability to create a new release and trigger a deployment when a new package is pushed to the Octopus server. Combined with Octopack, this makes continuous integration very easy from Team Foundation Server.

    What if you need to sync files manually?

    Then you should use an FTP client, which allows you to update files you have changed. FTP Sync and Beyond Compare are recommended as they compare all the files on the web server to a directory on a local machine, including date updated, file size and report which file is newer and what files will be overridden by uploading or downloading. you should only make changes on the local machine, so we can always upload files from the local machine to the web server.

    This process allows you to keep a local copy of your live website on your machine - a great backup as a side effect.

    Whenever you make changes on the website, as soon as they are approved they will be uploaded. You should tick the box that says "sync sub-folders", but when you click sync be careful to check any files that may be marked for a reverse sync. You should reverse the direction on these files. For most general editing tasks, changes should be uploaded as soon as they are done. Don't leave it until the end of the day. You won't be able to remember what pages you've changed. And when you upload a file, you should sync EVERY file in that directory. It's highly likely that un-synced files have been changed by someone, and forgotten to be uploaded. And make sure that deleted folders in the local server are deleted in the remote server.


    If you are working on some files that you do not want to sync then put a _DoNotSyncFilesInThisFolder_XX.txt file in the folder. (Replace XX with your initials.) So if you see files that are to be synced (and you don't see this file) then find out who did it and tell them to sync. The reason you have this TXT file is so that people don't keep telling the web

    NOTE: Immediately before deployment of an ASP.NET application with FTP Sync, you should ensure that the application compiles - otherwise it will not work correctly on the destination server (even though it still works on the development server).

  4. Do you know how to handle diacritics?

    Imagine you're developing a search feature for a multilingual website. When a user searches for a term like "résumé", but the database contains variations like "resume" without accented characters, it leads to missed matches and incomplete search results. Furthermore, this lack of normalization can introduce inconsistencies in sorting and filtering, complicating data analysis and user navigation.

    Implementing character normalization by converting accented and special characters to their closest unaccented equivalents allows terms like "résumé" to match "resume" enhancing search accuracy and overall user experience by addressing these multilingual nuances.

    This is especially important for internationalization and for sites to serve users worldwide effectively, regardless of linguistic differences.

    Handling diacritics in JS

    JavaScript provides us with a handy method called normalize() that helps us tackle this problem effortlessly.

    The method takes an optional parameter specifying the normalization form. The most common form is the Unicode Normalization Form Canonical Decomposition (NFD), which is suitable for most use cases.

    See Unicode equivalence

    Let's see how we can use it:

    const accentedString = "résumé";
    const normalizedString = accentedString
      .replace(/\p{Diacritic}/gu, "");
    console.log(normalizedString); // Output: resume

    There are 2 things happening in the code above:

    1. normalize() converts strings into the NFD. This form decomposes composite characters into the base character and combining characters. E.g. 'é' would be decomposed into 'e' + '´'
    2. replace(/\p{Diacritic}/gu, "") matches any character with a diacritic mark (accent) and replaces it with an empty string

    Handling diacritics in .NET

    You can also achieve the same result in .NET using a similar method Normalize():

    string accentedString = "résumé";
    string normalizedString = RemoveDiacritics(accentedString);
    static string RemoveDiacritics(string accentedString)
        Regex Diacritics = new Regex(@"\p{M}");    // A regex that matches any diacritic.
        string decomposedString = accentedString.Normalize(NormalizationForm.FormD);   // Equivalent to NFD
        return Diacritics.Replace(decomposedString, string.Empty);
    Console.WriteLine(normalizedString);    // Output: resume

    Voila! With just two line of code, we've transformed the accented "résumé" into its standard English form "resume". Now, the search functionality can accurately match user queries regardless of accents.

    Note: While this method often ensures uniformity and handles characters with multiple representations, it may not function as expected for non-diacritic characters such as 'æ' or 'ø'. In such cases, it may be necessary to use a library or manually handle these characters.

We open source. Powered by GitHub