So now that we’ve defined tech stack and why you should care about it in part 1, let’s discuss the two main components of a tech stack (good or bad can be part 3).
(Very) brief:
Tech Stack = client-side (front-end) + server-side (back-end)
CLIENT
Client-side technology provides everything needed to build and facilitate the user experience of your application. It is important to note that an app’s front end SHOULD:
1. be configurable
2. optimized as per the app requirements
3. be able to handle operations through interactions
Common client-side technologies include:
1. Markup languages (HTML, XML, XHTML)
2. Stylesheets (internal, external and inline CSS)
3. Specific programming languages (JavaScript, Xamarin)
4. UI frameworks built upon a programming language (ReactJS, AngularJS, both built on JavaScript)
SERVER
Server-side technology connects the user interaction or UI with subsystems that perform logic, interact with databases etc.
Common server-side technologies include:
Specific programming languages (C#, Java, PHP, Python)
Frameworks built upon a programming language (Node.js built upon JavaScript, .NET built upon C#, Django built upon Python)
Databases (Microsoft SQL Server, MySQL, PostgreSQL)
Cloud infrastructures (AWS, Microsoft Azure, Google Cloud)
Choosing the right stack (if you’re a developer)
1. Consider the size and purpose of the application. Review all the detailed features that are needed.
2. Find the sweet spot between the tech that you already know with a little amount of “new”, especially if your team is already comfortable with a particular stack.
3. You might find efficient people who work with legacy languages, however, if it compromises your ability to maintain a project in the future OR integrate with other tools then consider talent with a more contemporary stack.
4. Your tech stack should enable the app to absorb your planned growth so consider scalability at the architectural level.
5. Scalability also depends on your cloud servers, so vet your hosting and ensure it can manage reverse proxies, load balancing, etc.
6. Compatibility with third parties should be a major consideration when choosing a stack. If a third party doesn’t have an SDK in a language that your stack relies on, then you can’t use that service.
Duh I’m a marketer/ operations/ brand or a human from any other non-tech discipline. How do I figure out the right stack. Who do I ask? What do I say?
Well, you don’t need to figure out the right stack for yourself. A System Architect should. What you should do is:
KNOW
1. What you want the application to do. Sit down with the team and map out the desired features of your product with all the key stakeholders involved in your project. At the end of the day, everything needs to align with the business goals of the product which you should know BEFORE you start.
2. Your business case for the product. For example, you’re launching a loyalty program. Your tech team is responsible for the stack, but you’re responsible to really know and decide on how you want the program to work in a way that it’ll serve the business objectives that you set.
ASK
1. Ask your technical team if they have all the information they need BEFORE they decide on the stack.
2. Ask your vendor what level of data encryption they use and if they monitor for breaches and service intrusions.
3. What does your development roadmap look like?
Stay Tuned for Part 3
Read the original post here:
https://rlabgroup.ca/home/f/jargon-demystified---tech-stack-part-1
