bnjns
commented
4 years ago In GitLab by @bnjns on Apr 27, 2020, 23:15
changed due date to June 01, 2020
Closed bnjns closed 4 years ago
bnjns
commented
4 years ago In GitLab by @bnjns on Apr 27, 2020, 23:15
changed due date to June 01, 2020
bnjns
commented
4 years ago In GitLab by @Hypothawits on May 6, 2020, 20:47
Two parts, my response and then a summary of a response someone sent to me: Part Me: I'm sure I've already made it known I'm in favour. I feel the learning curve of the current setup prevents a lot of members from feeling like they can contribute. Moving to new language(s), that are closer to what we learn at Uni makes it easier for people to get involved without any prior knowledge. I worry that it's a big task for one person, but I also hope that people would be able to get involved at an early stage.
Part 2: It looks really well thought out, and the reasoning made is great. Personally it doesnt really matter what the language is cause I would have to learn from scratch anyway. Making it better organized sounds incredibly important especially for complete beginners like me. It would be really good if we could integrate Angels asset register (I know he will need to rewrite it) and the finance database and it can be easily updated.
bnjns
commented
4 years ago In GitLab by @bnjns on May 6, 2020, 22:07
Thanks for the responses!
To mitigate it being a lot for one person, I'm hoping that we can approach this in a far more reasonable manner and simply work on an area (or part of an area) and merge it in. This would certainly help others get involved as they can get stuck in straight away, and tackle a small part. Take the current MR as an example - I'm already merging into master to keep it small and manageable.
bnjns
commented
4 years ago In GitLab by @jordanlkirk99 on May 6, 2020, 22:26
As one of the few members to attempt to help, I should chime in. I was significantly hampered by my lack of knowledge of Laravel and website development in general. The structure (which appears to be as Laravel expects) splits the website structure up quite a bit, leading to having to jump around a lot. Plus the amount of abstraction lead to a lot appearing to happen as 'magic'. Not obvious where UI was pulling it's variables from etc
For your proposed languages and frameworks I can't really comment due to my lack of knowledge / experience in the web dev world. Typescript sounds better than traditional JS from the little I know. Kotlin dosen't seem to be that common in the web world, but it's very common on Android so hardly that obscure. If we're going to redo (potentially just you) the website using the same / similar tech you use professionally has its benefits.
bnjns
commented
4 years ago In GitLab by @bnjns on Jun 1, 2020, 22:14
This has been approved :) The current MPA is now frozen, with only major or urgent bug fixes to be worked on.
bnjns
commented
4 years ago In GitLab by @bnjns on Jun 1, 2020, 22:14
closed
bnjns
commented
4 years ago In GitLab by @bnjns on Jun 1, 2020, 22:15
locked this issue
bnjns
commented
4 years ago In GitLab by @bnjns on Jun 2, 2020, 18:19
unlocked this issue
bnjns
commented
4 years ago In GitLab by @bnjns on Jun 3, 2020, 20:33
locked this issue
In GitLab by @bnjns on Apr 27, 2020, 23:15
Request for Comments
Summary
This RFC is formalising the proposal for the website to move from the current Multi-Page Application (MPA) to an Application Programming Interface (API) for the logic and data access and a Single-Page Application (SPA) for the user interface. For a brief description of what these are, see this article on MPAs vs SPAs and this one on APIs.
TL;DR:
Motivation
The key issues
While there is nothing fundamentally wrong with the current site its size is making it progressively harder to maintain; this problem was particularly apparent once we began to plan how to integrate the finance and asset databases into the main site. The tight coupling between the business logic and presentation layer, as well as how Laravel apps tend to organise their files, has made it difficult to design the integration in a manner that is easily maintainable. This is a key factor in why progress into the asset database stalled early into the planning stage.
The few members who have become involved with the maintenance of the site have also frequently commented on the structure of the site being a significant learning curve that took them a while to understand. Due to the way Laravel works, a lot of boilerplate framework code is mixed among the application code making it harder to understand what's what. This is then exacerbated with the added need to understand where the presentation layer is stored, and how it integrates with the controller layer.
It is worth being aware that the size of this application already makes it similar to many small or even medium-sized enterprise applications, even though we do not use enterprise-grade hosting (such as AWS or GCP). It is important that the language and framework we use is designed for this size of application, and allows it to grow with time while retaining maintainability.
Why use an API and SPA
A common pattern nowadays is to break the business logic and presentation layer up into separate applications; the primary benefit of this is that it de-couples the data from the presentation, allowing each to be developed independently.
You can choose the most appropriate stack for each layer
Frameworks are often designed for a particular use case; several frameworks exist that are aimed at purely developing APIs or SPAs - and as they only have a specific use case to support, they excel at it. Separating the front and back ends in this manner enables you to select the best framework for the use case and your team's skillset(s).
Easier to understand
By breaking the code up, it's much easier for a newcomer to understand the code at a glance. They can easily focus on a particular aspect, without any additional knowledge needed to understand the tight coupling.
Development is often much quicker
It's much easier to develop a smaller code-base. Many of issues with MPAs is designing and developing the business logic in a way that's compatible with how the presentation layer needs to be built. When developing an API, you no longer need to worry about this as you are simply dealing with pure data as your inputs and outputs. The same is true of the presentation layer; you don't need to worry about where the data comes from - all you need to do is present it in the UI and allow the user to interact with it. This has a further benefit of allow multiple developers to work alongside each other; one can focus on the API while the other focuses on the front end.
"Full Stack" is a lie
The idea that developers are "full stack" (equally proficient at both the front and back end) is often wrong; most developers have a natural preference for one end, and while the may be involved in the other side of the stack they will always be more efficient with their preference. Using an API and SPA allows your development team to work to their strengths, resulting in more of a speed boost and a better code base.
Rapid Prototyping
Another benefit of de-coupling the presentation and data layers is that it allows much more rapid prototyping. It's much easier to design and develop the business logic when there's no need to worry about the how to present it to the user. The presentation layer can then be worked on later on, or even at the same time if the interface is agreed beforehand. What may take months to develop in an MPA can take weeks if not days as part of an API.
The proposal in this RFC is to use the following:
Why Kotlin (and Quarkus)
Both Kotlin and Quarkus are likely the least known of the 4 proposals in this RFC.
Kotlin is developed by JetBrains and is a replacement for Java. It works on the JVM, so gains the cross-platform compatibility that made Java popular, but brings many modernisations that make it a joy to work with. For any one with knowledge of Java (or Scala/Clojure), chances are Kotlin will be a small learning curve; even for those with C/C++ knowledge it's still relatively similar and so the learning curve is likely very similar to that of PHP. While Kotlin is not that new a language, it recently became Google's recommended language for Android development, and is slowly becoming popular in the enterprise industry too.
Quarkus is very new framework, built to the new microservices specification. While this site won't be using a microservice architecture, it's simplicity and speed is a huge benefit. It leverages many benefits from the JVM ecosystem, such as annotations to reduce boilerplate code, and you can organise your code base however you want - it also has the benefit of including no framework code within your application
Kotlin and Quarkus are both used at my job, which would bring the added benefit of making it easier for me to work on the site; at the moment the need to switch to PHP/Laravel makes it difficult to get any significant work done.
TypeScript vs JavaScript
JavaScript has been the champion of front-end for a while, but suffers as a result of its age. Its lack of real typing can lead to some unusual or unexpected type coercion that makes code very prone to developing bugs.
TypeScript, developed by Microsoft, aims to solve this problem by bringing static typing (where the types are checked at compile time) to JavaScript. While it is community-driven (most of the types must be provided as separate packages by the community), applications that use static typing see far fewer bugs than with dynamically-typed languages.
TypeScript may have a steeper learning curve than pure JavaScript, and issues can be encountered when packages are missing or have incorrect type, but once familiar with the syntax it will become second nature. TypeScript and Kotlin also share a lot of their typing syntax, which would make switching between the API and SPA significantly easier.
Drawbacks
The most significant drawback is additional development time. If we choose this, it will be very difficult to both maintain the current MPA alongside the new API/SPA. Bugs and critical improvements will still be possible, as long as they aren't too complex, but any new significant features will need to be postponed until after the API/SPA is complete.
This would also necessite a change in deployment mechanism; shifting towards Docker images. However, was already planned for the MPA and is a key factor in the decision to change hosting provider.
Moving to 2 separate languages and frameworks will add a learning curve; however the similarity in languages and de-coupling should mitigate this such that it is no worse than the current learning curve.
Alternatives
Continue with the current MPA
It would be possible to continue with the MPA; however a significant re-factor would be needed in order to bring the same medium/long term maintainbility of an API/SPA and would likely be a similar amount of effort.
Use Laravel for the API
Laravel can function as a pure API rather than an MPA, making it an alternative to Kotlin/Quarkus. This would still suffer from some of the organisation issues that are part of the MPA, and there seems to be limited support for using JWT (JSON Web Token), which is an widely-adopted authentication and authorisation mechanism for APIs.
Use Python
Many people will be wondering why this doesn't consider Python as an alternative, if we are considering changing the language. At first glance Python might seem a good choice; it has become a fairly popular language due to its apparently small learning curve and focus on forcing well-structured code through whitespace significance. However, Python lacks a lot of common Enterprise features, such as static typing and good Object-Oriented support (and has no functional programming support). There are few choices for frameworks, and both are difficult to work with. It is also one of the slowest interpreted languages and has a very poor package management solution making it very painful to develop any significantly-sized application.
Adoption Strategy
The first step would be to move the existing functionality over to the API/SPA. This would not need to be completed in one go, but instead could be developed in chunks. While we wouldn't switch over until the entire site is complete, this would offer a unique opportunity to distribute knowledge of the website around any members interested in becoming involved.
The second step would be to decide on the new hosting provider. It would be sensible to make this decision (or at least part with money) once the site is closer to completion as this will allow a more seamless transition between the old and new sites; the new site could be tested independently and then the DNS simply updated to switch over.
\label ~"type::rfc"