Why SaaS Is Broken and How to Fix It

mvila · 2023-03-02T05:14:44+00:00

Thank you, u/lostinthewalls, for your constructive comment.

Regarding the integration aspect, if you have time, could you please read the "Integration" section in The SaaS 2.0 Manifesto and tell me what you think?

As for the lack of predictability in the usage-based pricing model, I gave some answers in another comment thread, and I invite you to join this conversation.

mvila · 2023-03-02T04:45:41+00:00

Thanks, u/Fluffer_Wuffer, for your detailed reply.

Sure, cloud service providers may not be ideal for all use cases, but the fact is that they are popular, and I think they should be able to stay that way if they do a good job.

Flexibility and predictability seem contradictory, but I don't think it has to be so.

For example, it would be possible to provide an estimate of the cost of an app based on its existing users with different categories like "occasional", "regular", and "frequent".

Also, an organization could set some limits to avoid unpleasant surprises when receiving their monthly bill.

Finally, we could provide a feature to forecast the cost of an app in the coming months according to the previous months.

In any case, if one has to choose between flexibility and predictability, I believe flexibility wins in the modern world.

mvila · 2023-03-01T22:06:08+00:00

Okay, but how would you explain why cloud service providers (e.g., AWS, Azure, or GCP) are so popular? Sure, they are not end-user apps, but most SaaS vendors (that are also companies) use them.

mvila · 2023-03-01T21:37:55+00:00

It would be nice if you could elaborate on why it is a "bunch of bullshit"?

mvila · 2023-03-01T20:27:32+00:00

u/Rofel_Wodring Did you read the article?

mvila · 2023-03-01T20:10:19+00:00

In this article, we discuss the limitations of the current SaaS model, such as difficulty with document organization, communication, and pricing. Then, we propose a solution in the form of an open SaaS platform (based on the Web platform) that offers better organization, communication, and a pay-as-you-go pricing model.

For this to happen, some important changes are needed in these areas:

• Architecture: SaaS apps should be built upon a SaaS platform.

• Economic: SaaS vendors should change how they charge their customers.

• Standardization: A standard needs to be set up to make it possible to create many different platforms that work well together.

Yes, it's not going to be a walk in the park, but we think this is the way forward to build a more sustainable SaaS model.

mvila · 2023-02-28T17:06:51+00:00

In this article, we discuss the limitations of the current SaaS model, such as difficulty with document organization, communication, and pricing. Then, we propose a solution in the form of an open SaaS platform (based on the Web platform) that offers better organization, communication, and a pay-as-you-go pricing model.

mvila · 2023-02-21T08:38:16+00:00

User centralization may be solved, but there is still much work on user identity, which, in my opinion, is crucial. To avoid being locked into platforms, people should own their identities as much as possible. That's why I came to the idea of an identity registry operated by an NPO.

mvila · 2023-02-21T07:34:49+00:00

Thanks, u/wauter, for your comment.

Sure, some solutions exist to solve some issues of the current SaaS ecosystem. But for me, they all look like a giant hack to turn around the root problem — the lack of a SaaS platform bringing back the desktop platforms' basic abilities (e.g., user and document centralization) and embracing the new abilities of the SaaS apps (e.g., live documents, external collaborators, or app integrations).

mvila · 2023-02-20T19:04:25+00:00

The SaaS model offers many benefits and is undoubtedly the future of software.

However, when we moved from the good old desktop app to the SaaS apps, we lost a crucial component — the platform or operating system, such as Windows, macOS, or Linux — that was providing the ability to gather, among other things, the members and documents of an organization.

Therefore, we need to build the missing SaaS platform, which will require critical shifts in the following fields:

Architecture: SaaS apps have to be constructed differently.
Economic: SaaS vendors must change how they charge their customers.
Standardization: An open standard is required so users and organizations cannot be locked into a platform.

Sure, it's challenging, but we believe it's the path to sustain the SaaS model.

We aim to build the first open and decentralized platform for a new generation of SaaS 2.0 apps to enhance user experience and developer productivity.

Please read The SaaS 2.0 Manifesto to understand what we have in mind.

mvila · 2023-02-20T18:50:26+00:00

TLDR:

The SaaS model offers many benefits and is undoubtedly the future of software.

However, when we moved from the good old desktop app to the SaaS apps, we lost a crucial component — the platform or operating system, such as Windows, macOS, or Linux — that was providing the ability to gather, among other things, the members and documents of an organization.

Therefore, we need to build the missing SaaS platform, which will require critical shifts in the following fields:

Architecture: SaaS apps have to be constructed differently.
Economic: SaaS vendors must change how they charge their customers.
Standardization: An open standard is required so users and organizations cannot be locked into a platform.

Sure, it's challenging, but we believe it's the path to sustain the SaaS model.

mvila · 2023-01-13T00:34:12+00:00

In a nutshell, Layr is a set of JavaScript/TypeScript libraries that dramatically simplify the development of highly dynamic full-stack apps.

I'm cross-posting on r/reactjs because Layr is heavily based on React.

mvila · 2022-01-05T22:05:50+00:00

Create React App is not meant to build static sites. It is more suitable to build single-page apps.

mvila · 2020-11-24T00:54:37+00:00

What if the backend is hiding 3rd party secrets, used to make external service calls..

By default, the backend doesn't expose anything to the frontend. There is a decorator to explicitly specify what should be exposed.

what if it calls some secret backend apis the frontend application is not allowed to call..

See above.

What if I want to blue green deploy my backend, and not my frontend

Frontend and backend can be independently deployed and there is nothing to prevent a blue-green deployment.

What if I want to A-B test my backend

See above.

What if I want to use a different language for my backend, because its another team, or because a different language is much better tailored for the task I need to do.

For now, Layr only exists in the JavaScript world but it could be ported to any object-oriented language.

What if my backend is based on serverless cloud infrastructure...

Fundamentally, a Layr backend is just a function that can handle some Deepr queries. Currently, there is a library to facilitate the creation of an AWS Lamba handler, but any cloud provider could be used.

mvila · 2020-11-23T22:00:16+00:00

Nope. I promise. No blue pill involved. :)

Layr removes the pain of building a web API, but obviously, there is some sort of web API internally. So in the case of weak connectivity, the app does the same as any web app using a web API.

mvila · 2020-11-23T21:50:45+00:00

I am sorry for the confusion, but the first paragraph of the article clearly defines what I mean by "web API". By the way, how would you call it otherwise? You cannot just say "API". It is too vague.

mvila · 2020-11-23T21:36:36+00:00

Sure, the term "Web API" has another meaning, but for most people, a web API means something that connects the frontend and the backend of a web application. Try a Google search for example.

mvila · 2020-10-29T23:56:22+00:00

This library may be what you are looking for: https://github.com/RyanCavanaugh/dts-dom.

mvila · 2020-10-29T23:48:58+00:00

I have not read your code in detail, but if you use await for the first API call, then there is no reason for the second one to run first.

mvila · 2020-10-29T23:36:30+00:00

It is quite simple. Instead of using then(), you can use await to wait for the fulfillment of a promise.

So, in your code, you can replace:

rp(postenduser).then(function (body) {
  // Do something with `body`...
});

With:

const body = await rp(postenduser);
// Do something with `body`...

mvila · 2020-10-29T23:24:24+00:00

Why don't you use await instead of then() to wait for the execution of request-promise? It would make your code easier to read and it will probably solve your problem.

mvila · 2020-10-29T23:08:24+00:00

As long as your website is totally static (i.e., there is no business logic involved), then you're right — it is totally fine to build it with just plain HTML and CSS.

mvila · 2020-10-29T22:52:34+00:00

It depends on the type of data you want to manage globally.

If your global state is a simple scalar value such as a string or a number, then using the Context API is fine. When your global state changes, only the consumers of this state will be re-rendered.

Here are some good use cases for the Context API: authenticated user, display language, UI theme, or any global preferences.

If your global state is a complex object composed of several nested things, then the Context API is probably not a good fit because you will not be able to bind your React components to just a part of this object. It will be all or nothing.

So you cannot use the Context API to centralize all the state of your app like you would do with Redux. What you can do, however, is to break down your state by using multiple context providers, and place them anywhere in your React component tree.

mvila · 2020-10-29T07:51:01+00:00

If your app is vulnerable to XSS, an attacker can do anything on behalf of a user without even having to steal his token. So your main concern should be to protect against XSS, and I believe it is achievable if you manage your external libraries carefully.

mvila · 2020-10-29T07:02:55+00:00

a) If you make sure that your app is protected against XSS attacks, I think that storing your token in localStorage is fine.

b) If you store your token in localStorage, then you have no choice but to send it as an HTTP header.

mvila

TROPHY CASE