u/ErinPearler

Building a trading SaaS application for the last few weeks.

Right now I have a cloud server, python server and html file. I think probably 2000/3000-5000 lines of code. Many features that my application offers.

Of course there are bigger sharks comparing my application to theirs.

I have no customers right now, not even charging for my website.

But my question is... What makes SaaS company valuable?

Is it the features a code offers, customers, traffic?

For example: A rival big company that is similar to mine is "Finviz" the stock screener. They are completely free to use but you can pay. Another is barchart I checked how much traffic they have and they have millions of visitors per day, free to use but they lock the site after you view 20 webpages.

I know some companies get bought out before they go public just because of the wow factor, my project isn't anything special but whats something I can do to make it more unique?

More features, charge users, make it different from others?

This is my first software project new to the field. Sorry if this question is a basic business question might sound dumb to some pros.

I was hired into my current job to do React and Angular development and, by the way, we have this WordPress site so we need someone who can do that too. And I told them in the interview that I'd worked with WordPress for 7 years, but that was 5 years ago and I'll need time to get back up to speed. So I was hired, and the WordPress site in question has pretty much become all I do.

I'll be honest, I don't like WP that much. But, we all have to work so I set about trying to make it enjoyable and I hit upon the Timber library. The appeal to it was I've done work with Drupal, I actually have contrib credits in that project, and as of Drupal 8 it uses the Twig templating system. Timber is a binding library to allow Twig to be used seemlessly in WordPress.

First question - why do this? Answer, full Model/View/Control architecture. WordPress out of the box muddles control code with view code in it's endpoints. Another pain point, for me at least, is "The Loop". I hate it. Functions with state are notoriously hard to unit test. Having to be careful not to switch up critical post variables while parsing a block is just a headache. I will grant, these are statements of programming philosophy and I fully expect disagreement. But if I'm going to be maintaining a website for the next several years I need to be able to be comfortable with it.

I walked into a nightmare theme base. The design firm handed off a site with a broken search feature and several blocks misbehaving. The code... oh the code. I'll give one of the worse example - there's a service directory block that displays every letter of the alphabet to allow a fast hop to the section of the page with services starting with that letter. The block file for this was 1200 lines long. The coder had copy pasta'ed every letter of the alphabet. After refactor the control code was 40 lines long - the twig template is 60 lines. 100 in total.

It was during this refactor I ran into the newer block.json pattern and fell in love - that makes sense. ACF blocks also make sense.

Eventually I converted the site over to using twig templates, and with that in place I wrote a test system to test those templates and their attendant CSS and JavaScript. See, the twig templates just need data loaded into them - they don't care where it came from. In my test system I can load "lorem ipsum" to my heart's content and not worry about the test breaking if someone edited the test page.

I test my site using Playwright ( r/Playwright ). The PHP side stands up one block at a time - and it's guarded to only respond if WP_DEBUG is on so in production the code is inaccessible. Playwright then iterates through the result. It can also provide data to be displayed, or change variables resulting in different color schemas being applied. The 200 (at the time of this writing) tests scan for the correct colors being applied and reference screenshots are taken to see if the rendering is correct. Each test is ran through 10 different device profiles, so 2000 runs occur. Takes my Mac about an hour to run the whole suite, which I do before pushing a change such as the upgrade to WP 7.

It takes away a lot of headaches, but it creates some. Timber is reliant on composer, and WordPress doesn't natively support composer. I use an mu_plugin named "00_autoload.php" to load composer ahead of all other plugins and it works, but it does mean my themes and plugins are not portable to other sites.

That's sad to me. I looked over on trac and there is a discussion on composer's inclusion I've joined - https://core.trac.wordpress.org/ticket/47256

I've also given some thought as to why this situation arose, and it's largely due to the inability of PHP to alias namespaces to allow plugins the ability to run different incompatible versions of the same library where necessary. Hence I've been active on the PHP-DEV list to try to come up with an RFC for such functionality.

For the moment I'm seated in on this. I'll keep an eye out on things I can help with, and if anyone has any questions fire away.

A couple of websites on my server have started redirecting to strange very spammy sites.

My domains are:

https://gallery.bentsea.net

https://animeoklahoma.com

These are both static websites. Does anyone have any idea what could cause this on a static website with no interactivity?

I've seen so many threads discussing auth across multiple subreddits and without fail there's always a few comments giving this "golden rule" without any other explanation. It's a meme at this point.

While there is merit to this advice I think it's horribly misunderstood by many who regurgitate it with no regard as to its original intention.

When people do explain why they are telling OP to not implement their own auth there's always these factions:

1. "Just use an existing provider, you will never be able to make yours secure, why risk it"

2. "Please clarify what you mean by implementing your own auth, if you are thinking of writing your own oauth2 spec, or hashing libraries please don't!"

The second point I think is what this "golden rule" was actually originally intended to say and you should EITHER use known libraries OR providers.

The first point one can be valid, but ultimately seems extremely disingenuous. Most of the time the threads are asking about some simple webapp OP is building where the only authentication layer needed is basic user auth - create, login, sesions / jwts, and pw management.

As long as you use known secure standards and libraries such as (eg. for python) argon2 via pwdlib or JWT tokens via pyjwt you can very easily and securely implement those functionalities, and save the bloat and or money from using a provider. And as long as you're a competent developer, and not haphazardly implementing faulty business logic where these functionalities exist then for those basic functionalities you should be plenty fine.

It also means that as the developer you will be more in tune and knowledgeable with the inner workings of your system, a bonus many seem to disregard.

The only persuasive argument I've seen about not using libraries for auth implementation was about how they can be incorrectly implemented in the business logic which opens up vectors for attack. While true, these basic functionalities are heavily documented and honestly require minimal lines of business logic code, so as long as they are implemented half competently these libraries should handle the vast majority of the possible attack vectors. Moreover, if you use a provider you still need to implement their API's using business logic, so it doesn't matter if your auth provider is ironclad if your overall business logic is insecure.

So I say this, don't implement your own authentication if by that you mean writing your own specs and libraries (unless youre doing it for fun and as a learning experience) but by all means if you are writing a basic webapp with basic authentication requirements, go ahead, that is why they are there and a tonne of people use them daily. Just make sure you have a good understanding of basic auth principles and by god read the documentation.

I may be wrong and am happy to change my mind, but I think authentication is weirdly gatekept and people lose the opportunity to become better developers by implementing it through existing libraries rather than outsourcing it to some provider.

Or as the people from the third faction of answers on auth threads that I did not mention above say:

-"Fuck it, build it, learn from it!"

List some underrated api's