simplotek

> Being an OAuth 'provider' (emphasis) is not open source

Being an OAuth provider is precisely what everyone expects from a self-described "open source authentication service". If Supertokens does not support that out of the box, it should not really be called an open source authentication service.

I understand you want to capitalize from your work, but I feel this is a gross misrepresentation of a project.

> My personal pet (non scientific) theory is that repeated infections over-sensitize the immune system, almost like an allergic reaction or something.

There have been a few variants that have a markedly change in their ability to spread and also their severity. They might be hitting people differently. I mean, if the same person is getting infected multiple times with carrying degrees of severity, something is changing in the infection.

You are oblivious to the point of this approach. Scaling has nothing to do with it. It has everything to do with not imposing useless and detrimental constraints that buys you nothing but problems. You specify interfaces, and keep implementation details from leaking by encapsulating and insulating them. This is terribly basic stuff.

> How can you get any work done like this?

People get work done by knowing what they're doing, which I'm not sure you are able to tell.

There is plenty of literature that explains quite thoroughly the process of software architecture. Basically all major software architecture styles from the past four decades reflect the need to encapsulate and insulate implementation details, including the need to specify a domain model and how it should be specific and exclusive to each project.

Somehow, you are oblivious to basic principles but still feel entitled to insult others based on domain knowledge you clearly lack.

> Should both my service and Galactus have full, individual copies of this data structure?

Yes. I recommend you read "Domain-driven design" by Eric Evans, specially the part explaining the concept of a bounded context.

> Alternatively, if Galactus has a published schema that I refer to, isn't that a shared data structure?

No, that's the interface.

> not only we deduplicate code

You don't. You just needlessly add a constraint for no reason at all, and in the process make your life a mess.

> They recommended I use "modern infrastructure" which means Docker.

It looks to me they recommended to never consider Datadog for anything whatsoever, ever again.

> but I agree, this is not something that i've ever considered when filtering CVs.

As a proficient LaTeX user, this is the stupidest take I ever saw on resume tips. I mean, your skills and experience do not vary with the document system you used to generate your CV. Some hiring managers swear by MS Word templates, other hiring managers ask for Europass, others ask you to fill in a form and request a cover letter. It would be stupid to assess the suitability of any candidate on this sort of bullshit.

> LaTeX for your resume?! If someone sumgly sends me a .TEX (...)

I'm not sure you got it right. You still have a LaTeX doc if you compile it to generate a PDF. LaTeX can have a very unique and peculiar look and feel that pops up to those in the know.

> That's only true if you are limited to two options

What other options do you think there are?

And consider that you're already talking about people which are fainting and suffocating.

> Early COVID-19 research found that most patients with optimum levels of vitamin D did not require ICU or breathing assistance and survived the infection.

Some sources point out that only 10-20% cases of covid are admitted to intensive care unit, and 80-90% of cases are mild.

I seriously doubt that up to 90% of the population has "optimum levels of vitamin D".

How teams interact is a function of the team/org, not the software architecture.

What microservices easily provide in this scenario that is far harder to pull off with a monolith is that with microservices the service owners are able to roll out a dedicated service as a deliverable from that dialogue. Whether the new microservice implements a new version of the API or handles a single endpoint, the service owners can deploy the new service as an extension to their service instead of a modification, and thus can do whatever they wish to do with it without risking any impact on their service's stability.

> If team A needs a new endpoint from team B, what would a typical dialogue look like under microservices and a modular monolith, respectively?

> Also, does ccache work with MSVC?

Technically it works, but it requires some work. You need to pass off ccache's executable as the target compiler, and you need to configure the settings in all vsproj files to allow calls to the compiler to be cacheable, like disabling compilation batching.

Using cmake to generate make/ninja projects and use compilers other than msvc is far simpler and straight-forward: set two cmake vars and you're done.

> Maybe, but after the next CEO comes in, those groups would be reorganised anyway :-/

That's perfectly fine, because microservices excel in that scenario: just hand over the keys to the repo and the pipelines, and you're done.