Distributed Application Frameworks and Standards

[rvanoord]

In order to be able to build new services quickly and independently - without making each service dependent on just one person and creating a maintainability nightmare - I believe there is an increasing need for some standards (perhaps in the form of existing frameworks) to build around.

Ultimately, we want to be able to dynamically expand our developer pool with community contributors, and then being aligned on "how we do things at BCC" should be an advantage - in order to maintain quality, and allow a core team to maintain the services after the community contributors move on.

At a very high level I think the following could be a start:

• OIDC for user authentication, OAuth 2.0 for client authentication and authorization
• Visual style guide (which the UX team is already working on I believe)
• Module level Web components as the building blocks for front-ends
• Open APIs (JSON-based) as the building blocks for public backends.
• Some sort of messaging infrastructure, and use of faster protocols (gRPC etc) between internal services. This is where I feel things are least defined.

dapr.io has been mentioned as a distributed application framework. It allows services to be developed in all the languages we love (node, C#, golang) and connects to different messaging services (pub/sub, azure service bus etc) - but probably runs best on Kubernetes. Perhaps there are other similar frameworks?

In addition, creating a consolidated set of public APIs might be best achieved by putting them behind an API Gateway. Again - this could be anything from a simple nginx proxy to a managed API Gateway service like Apigee. Again, are we at a stage that we should consider Kubernetes?

On the front-end side of things, we may need to define some "contracts" on how different modules should interact. Authentication is fairly straight forward, but things like navigation are a bit more tricky when combining web components. Perhaps there are some good frameworks or standards out there too?

I would love to hear all of your thoughts on how we can / should align and if there are frameworks or services (if any) that should or could form part of our "standard": backend, front-end, for messaging, for publishing APIs.

So what do we really want to achieve?

Ultimately we want to reduce coupling between services so that new services can quickly and independently be built, deployed, run (and replaced).
At the same time we want to align more strongly on the way we do things so that the end products are also aligned (consistent APIs, consistent user interfaces) and we have a larger pool of shared knowledge (reduce dependency on a single persons, faster incident resolution due a greater pool of experts with relevant knowledge etc.)

[rvanoord]

Azure Container Apps are the equivalent of Google Cloud Run (auto-scaling container apps, billed per CPU second).
Just saw that side cars (like dapr.io) are supported here: https://docs.microsoft.com/en-us/azure/container-apps/microservices-dapr?tabs=bash

This could be a good alternative to managing a full kubernetes cluster @KillerX

[KillerX]

When you firs mentioned this I was like: "it sounds too good for MS to have nailed it. I bet there is something missing that everyone had from day 1 that makes this not a viable competitor without significant extra effort."

And Hey, what do you know:

How to add SSL to Azure Container Instance App?

As far as I know, currently, there is still no built-in support for enabling SSL on Azure Container Instances.

Yeah there are several workaround, but I just can't believe that you have to "manually" maintain something that basic. It begets the question: "What else did they 'forget'?".

"removed" to not cause confusion, because Reng noticed it was discussing the wrong product.

[rvanoord]

"Azure Container Instance" is actually an older offering that has been around for a while.
"Azure Container Apps" actually supports SSL out of the box (not even optional). What it doesn't support though, is custom domain names. So the normal approach would be to add a gateway in front (e.g. Azure Front Door) which also would provide additional security features (WAF). This would of course only be required for the parts that are intended to be public. @KillerX

[KillerX]

I "love" the names of all this services (no azure is not the only culprit here).

[andreasgangso]

Maybe common tech isnt the way to go, only API standards? I'm scared to end up in a scenario we're locked in to using a unmaintained, legacy framework (and hard to understand because of a bunch of abstractions).
I honestly havent looked deep into what dapr does but from a glance it looks like it affects quite a bit of the app code.

Anyway, a framework is probably a waste of time if we're only talking about 10 services. I don't see us needing to have many tens of microservices, which Dapr seems to be built for.

[rvanoord]

Very valid question. I do believe we will have many 10s of services across the board - but share your concern with being locked into an unmaintained legacy framework. That's actually also a driver for building smaller, loosely coupled services.

[piotrczyz]

I share the same concerns - possible we won't have many manageable services and we need a framework. Well documented API would be a good starting point - the way we model our APIs. We could think of integration systems like Apigee or Snaplogic.

[piotrczyz]

As far as I saw there was more like SDKs that you include into your code. So it will be just matter of a configuration, I suppose @andreasgan

[KillerX]

@rvanoord but will we have 10s of services that constitute one product? I for example want to interact with members, not with login service, nickname service, address service, church locator service, thumbnail profile picture service. That should be the internal implementation of the "Members" product.

And to be honest for example for us at BCC.Media, I don't see a strong need for any kind of non-monolith oriented arch. So if everyone exposes their API in a sane way then it's just another API I have to integrate against. I already have to talk to the DB, Redis, PubSub, S3, MediaServices on Azure, Media stuff on AWS, and 10 other things, implementing one more API will not kill me.

Of note here is the definition of "exposes sanely":

• Something any (lets say TS, C#, Go as "any" for now) language can use, preferably something that can be generated
• Is well documented
• Is clear how to get access to
• Provides a test env to poke around

TLDR: IMO Standardize on standards not tools

[elpenny]

We discussed this a bit in a meeting but I want to leave a note here so it does not get lost.
TL:DR
It takes sizeable amount of time and effort to get into a state that we can use volunteered work in our projects.

Longer version:
In order to attract volunteers, in true spirit of FOSS, we should:

1. Prepare all repositories for external access (removing secrets, simplifying local setups, creating community guidelines, code of conducts, licenses, contributors agreements and so on, rewriting history to get rid of secrets...)
2. Prepare infrastructure providers with proper IAM (much more risks of someone gaining elevated permissions needs to be mitigated)
3. Raise a task force that would help facilitate communications between employed/contracted engineers and community (Community Manager role)
4. Have VERY GOOD public documentation, especially at system level.
5. Have VERY GOOD overview of 'Full picture' of BCC ITS responsibilities and their implementations.
6. Create some kind of advert campaign, people are not gonna work for us if they don't even know we want them to.

This is just short part of all requirements, I have 2 documents ready that you can read, which go more in-depth at
https://github.com/bcc-code/bcc-membership/blob/master/docs/guides/making-project-public.md
https://github.com/bcc-code/bcc-membership/blob/master/docs/guides/open-source-migration-guide.md

[kkuepper]

"At the same time we want to align more strongly on the way we do things so that the end products are also aligned"

There are different areas:

• Database (MSSQL, ArangoDB, RavenDB, Couchbase)
• Programming language (C#, node, GO)
• Cloud provider (AWS, Google, Azure)
• logging framework (ApplicationInsights, ...)
• messaging framework (dapr, NServiceBus)
• hosting infrastructure (Docker, K8s, AppService, ...)

In the listed areas we can't really agree on something and decided to go with a more flexible approach. Authentication and Json APIs are really easy to agree on. In general I think it's best to pick the best tool for the job and not worry about everybody trying to use the same tool.

But I don't think that our tools need to be aligned, so that the end products are aligned. Those are 2 independent things.

[kkuepper]

If we really want to "have a larger pool of shared knowledge" we should start moving people around. So far we have literally 0 movement between projects.

[piotrczyz]

Or even we should be as a one team that divides into smaller, per project teams (like JOS Room, Frabegynnelsen, Budget App?)

[andreasgangso]

I've heard having "project teams" is a bad idea, see e.g.
https://martinfowler.com/articles/products-over-projects.html#Conclusion
https://svpg.com/product-vs-feature-teams/

Personally I have no desire to jump between products.

[KillerX]

Ref jumping between products: First we need to recognize that we have in general 2 very distinct product types. On one side is the "fire and forget" like JOS room, FRBE, ... that can be considered "complete" and may require some maintenance if desired. On the other side we have Members, MyShare, Brunstad.tv, ... that are ongoing development.

Imo, you can reasonably easy have a team that "jumps" around on the 1st type of projects. That does not mean that they are working on 3 at the same time but they deliver and then "leave" to next project. I also thing that while exchange is good, a team where the members have worked together and know each others strengths and weaknesses tends to deliver quicker on clear goals.

The 2nd type of project generally "allows" for only a few types of jumping:

• Discussions about some specific points (can be at any level), I think we are going in a reasonable direction in the Moss office about this but we need to get better overall
• Bugfix type thing. For example if I get annoyed that something isn't working in MyShare API and send a PR
• "FireFighting" - That tends to be a specific type of person/experts who get utilized by all teams to solve very specific hard (for the project team) issues. Be it performance, security review, cross browser compatibility, you name it. But it's not "you are joining our team", it's either a loose person (like our dear friend Adelin) or a person from another team who has deep knowledge in an area (like Andreas is doing for BX).

[THISmann]

I personally have just read a little of the documentation of dapr I think it's a good idea but we must take more time to study the solution in depth and test it with our services. I imagine that our services will increase more and more

[elpenny]

I agree with @kkuepper here for the most part: we don't need to restrict ourselves to one tool in each category to align better end products.
And the only way to build shared pool of knowledge is to shift people around AND force every project to actually produce good, easy to understand documentation (looking at me and the rest of membership team :D). I think it would also really help if we could produce service map containing all services with clear separation who (teams) owns what (services and resources). Right now it is sometimes quite blurred.

[piotrczyz]

In our "playground" we have a huge benefit of using core(shared) services (boilerplates) for our microservices so that we don't need to do everything from scratch everytime. We consider to create NuGet packages so it will be easier to use.

I vote for empowering product/project teams by allowing them using of technologies they are most comfortable with (or depending on a use case). At least on the backend side :)

But an alignment within frontend (UI/UX), or way how we do stuff on the front end makes much more sense for me.

[piotrczyz]

Speaking of a number of microservices.. We work on our use cases across all our applications and we defined a "core" of all our applications, as far as we can see.
https://miro.com/app/board/o9J_lw6Isx4=/?moveToWidget=3458764518523372403&cot=14

Meaning that possible everything what is happening in BCC is often very similar with small deviations that could be extended by use of open APIs.

[rvanoord]

I think one thing that we need in addition to Open APIs (on the backend) is a standard for messaging. I agree that if we go towards a microservice type of approach, the language used in each service is less important.

I also think an API Gateway or simply a reverse proxy / web application firewall that puts all our services behind the same domain, may be beneficial for both security and alignment.

[RafalCypcer]

My few cents about Web components.

On the first look it seems as interesting solution, but digging deeper I'm afraid it will be too problematic.

Cons:

1. Web Components can be created by using TypeScript - but it requires to setup project, because finally we need to transpile to JavaScript - loosing types - it's a problem when we want to reuse Web Component in another project - we need to load JavaScript and what about typings? :) I cannot imagine to use any component without strongly typing in 2022.
2. Web Components uses JS class, so it means that we will use this which is very confusing mechanism in JavaScript, because of rules what this is specific depending on context where it's executed. Modern UI libraries like React with Hooks or Vue with Composition API solved that problem hiding this mechanism under elegant API reducing developers silly mistakes.
3. Web Components requires to hardcode HTML content which is created/modified during component events. Are we going to use solutions which enforces us to hardcode code? What about code quality that we discussed during workshops?
4. If we compare examples of how many lines of code must be implement with Web Components to implement logic (for example even with simple counter component which is kind of "Hello World" for UI libraries) and if we compare it with equivalent component with React or Vue so it means that Web Components requires from developer much more code. More code == more time for implementation, more places to make mistake, more time spend for maintenance etc.
5. Web Components cannot be versioned, because CustomElementRegistry is a global window object. The solution is discussed: Scoped Custom Element Registries WICG/webcomponents#716

If you google articles with Web Components limitations or flaws one the web there are many examples with developers issues and those solutions are in progress or they are temporary workarounds. Many of those issues don't exists in React or Vue ecosystems. For me Web Components still have to many issues which I cannot accept as developer nowadays - maybe in next years they will solve some of current limitations or issues. It doesn't make sense in my opinion use risky technology with poor support if we have already mature technologies on the market (like React or Vue) which were publicly released above 8 years ago and they solved many issues in their ecosystems.

[piotrczyz]

On the page above regarding Micro-frontend anarchy they mentioned that although this might be technically possible to use different frontend frameworks, it is far from advisable when not part of a deliberate transition strategy. Meaning that in the long run, we should aim for one frontend framework. Do you have any thoughts around it, @andreasgan ?

[u12206050]

Take a look at lit-js it supports any framework you want, but still allowing you to build pages using the same syntax which is kinda like web components.

[u12206050]

Personally I would like to stick with Vue but possibly look at how to have more static html components, since not everything has to be in JS.

[andreasgangso]

They sadly dont elaborate on why [it is not advisable]. But a few ideas: bundle size increase (no biggie for admin sites), knowledge sharing, inconsistent UX on components, etc. But the pros might heavily outweigh the cons.

I dont have more thoughts than this @piotrczyz .

[andreasgangso]

@u12206050

it supports any framework you want

I think you misunderstood what lit is? Support in lit's context means that the custom elements (webcomponents) made with lit can be used in any other framework. But this is no different from any other custom element using a shadow dom.
So lit is more relevant in another discussion about which frameworks to use. Also see the first reply in this thread from oskar about lit.

[andreasgangso]

https://konghq.com/ can be interesting as an api gateway. It's open source and used by big names.

[piotrczyz]

It looks interesting.