Software Architecture Suggestion: API + Web UI instead of Razor

I’m confused now. Are we expecting each site to create their own front end (writing vs stack overflow vs super user)?

What I notice right now is that our devs are not okay or are not happy with C# (including me) and would want it to change right now because if we didn’t then we won’t be able work with the full potential. I mean we have to build this and if we are not happy with our tech stack then how will we even be productive?

1 Like

We looked into this when we first had this discussion; again, I can’t find the link right now, but it’s a significant enough proportion that we can’t just dismiss those users. We need to offer a good enough experience without JS enabled that those users trust our platform enough to enable JS for it.

6 Likes

I am building a node.js proof of concept. If anyone wants to join me they can. I will post the link soon. I am not trying to compete with Codidact in anyway. Ideally Codidact would adopt this.

1 Like

That was a discussion 2 months ago, and people were happy with it.
And development has started now.

The people who are not happy with it are probably newer members here.
However, if we change the tech stack every time a new wave of members from another language comes in, we’ll constantly be designing the perfect system in the sky.

At this point, the only reason for changing the tech stack should be because some deal breaker is found. (Which is improbable because of all the ground work that has been done already).
Not because a couple of members would prefer a different tech stack.

14 Likes

Using an API requires client-side JavaScript, which a significant proportion of users still don’t have enabled by default.

This is not accurate. ES5 is widely supported. It should also be noted that those running IE 8 or lower are probably not interested in using Codidact. We can’t support everything - that’s simply not worth the development effort.

I am not opposed to generating static HTML. But it shouldn’t be the “default”. We should first build a REST API and then - eventually - search for a way to generate static pages.

I did not intend to start a discussion about changing the entire tech stack, but at the very least Razor.

@jbis I might want to join you. I think that the Codidact documentation & specification is certainly good, but I don’t like the direction the implementation is taking.

I think we should have multiple implementations. A NodeJS dev will probably never contribute to the C# implementation and vice versa. So they should be able to each try on their own, and in the end, we can chose the “best” implementation and officially “advertise” it.

Follow up thread: Multiple implementations, one specification.

2 Likes

Not enabled by default doesn’t mean the browser doesn’t support it. It means the user doesn’t allow it by default.

I usually have JavaScript disabled. Yes, it means that some web sites won’t work out of the box. Some (like Twitter) will offer me to go to a different interface that gives me the content without JavaScript. Some will just display a white page or a bunch of links to JavaScript.

There are enough web sites that work well enough with JS disabled. There are a few where it is obvious that JS will be needed (e.g. there’s AFAIK no way to show video without JS), so if I know that the site offers that type of content, I’m more likely to enable JS for that site. But in general, if a site required JS merely for reading, I’ll just go elsewhere. I generally need a good reason to enable JS on a site (and an even better reason to enable third-party JS).

Now I can’t tell how many other people are that way. But I know for sure that I’m not the only one.

10 Likes

There are other reasons as well, particularly:

Search Engines

Can search engines render a certain amount of Javascript and therefore work “anyway”? In some cases, yet. But far better (for a bunch of reasons) to provide content “ready to index”.

Deep Links

It is possible to make deep links work with a pure Javascript/API based view. But it gets complicated at times. Providing a full HTML output makes it easy as the server takes care of the URL evaluation and provides actual information instead of “a blob of Javascript code and hand off the parameters and hope that everything renders correctly”.

Alternative Output Formats

While already decided, despite my requests :frowning: , to not have native PDF output as MVP, at some point I hope we will have that as an option (PDF link on each content page to produce a clean, repeatable, nicely formatted Letter/A4 page in PDF format to archive, email or print). That is currently very hard to do in Javascript. Trust me. I’ve looked. A lot. And I’ve always ended up generating the PDFs server-side.

Accessibility

I can’t say for sure, but I have a hunch that a pure HTML page (even if it benefits from Javascript for user interactions) will work far better with screen readers for the blind and other assistive technology than a Javascript-based page.

7 Likes

Gotta be honest: starting up alternative implementations and casually dropping links feels a lot like “my way is best way join me”, whether or not that’s how it’s intended, which is… not particularly helpful.

For better or worse, .NET Core is our chosen stack. Would I choose something else if it were up to me? Yes, I would. Do I think .NET Core is the best possible choice? No, I don’t. Then why am I defending it, I hear you ask? Because core decisions cannot be up for constant re-debate by every new wave of folks joining. The only good reasons to change a core decision are (a) we find a dealbreaker, or (b) there’s widespread consensus for change despite setbacks.

I see neither of those here. If that’s what you want, start a thread and create consensus for change.


Transparency: I’ve deleted a post, above, that linked an alternative implementation. See above for reasoning: it’s unproductive to have this debate all the time.

26 Likes

I’d like to weigh in here as an experienced developer who primarily writes in JS.

I currently can’t contribute to the backend in this project because we are using .net.

…so what? Our goal is to build a robust back end not get as many devs involved as possible.

Whilst moving to RoR would be nice for my ego because I could contribute more, I don’t think moving right now is the right way to go. There were a lot of discussions about this and this is where we netted as a team. I voted for RoR and .net won. So I put on my big boy pants and contributed in other areas I have experience in.

We have to be able to make decisions as a team and stick to them otherwise we won’t make this project work. We can’t. There are too many decisions to make. And more decisive ones than this.

At the end of the day, contributing as much as you can will help us go further than complaining about tech stack. At the end of the day this is MVP. If we need to rewrite later we can. Although I highly doubt we will need to. Rewrites happen all the time in our industry. It’s how we have jobs

14 Likes

My personal opinion is that SPAs over complicate things for little to no benefit, except in the case that truly rich client-side interactions are a requirement. A Q&A website is not such a site, and traditional server-rendered HTML would be my strong preference.

It’s just as easy to correctly architect a server-rendered application to separate backend and frontend concerns as it is to do so with an SPA.

10 Likes

It’s the simplest possible way to build a site, that works in the widest variety of situations, and IMO should absolutely be the default for all new projects, even in 2020.

10 Likes

We can use Razor pages along with an API.

Personally I’m a fan of having an API, but don’t think we need to scrap Razor pages

1 Like

In that regard, some of our messages in mid-October from the #programming-general channel…

The following quotes are all mine except where otherwise noted; follow links at the end for context and surrounding discussion.

In my opinion, one of the main reasons SO/SE works so well, runs fast and with a very small bug/annoyance count, and was developed/is maintained in a timely manner, was due to their choice of tech stack.

They run ASP.NET C#, Microsoft SQL Server, with queries through Linq to SQL. The front end is Razor Pages, if I’m not mistaken, with custom JS and Jquery as needed.

I would like to propose we keep as faithful as possible to their choices.
But in order to reduce server costs, my choices would be:

  • ASP.Net Core (C#)
  • Entity Framework 6.3 (in the near future, Entity Framework Core, if it works well enough and support seamless many-to-many relationships as well as a few other pain points that I’m unhappy with right now)
  • MariaDB as the RDBMS, even though I do prefer Microsoft SQL Server, it is unfortunately expensive
  • At some point, optimize critical points with MongoDB, ElasticSearch or similar.

What I would be very wary of, personally:

  • PHP
  • NodeJS
  • React, Angular, -some other fancy, “no true HTML” JS framework

(https://discordapp.com/channels/634104110131445811/634374616646811648/634446406521978905)

SPAs are just not how the web is supposed to work.

Think HTML (and HTTP[s]) etc

the H stands for Hypertext

One document leads to another

That’s how browsers have been made to work since their inception, and it works fine enough.

SPAs subvert this core principle
And this leads to all sort of weirdness across various domains, much more than I’d be willing to go over in here.

Anyway, they do have their place. But those applications are very specific.

(https://discordapp.com/channels/634104110131445811/634374616646811648/634477620632879114)

The web has evolved, many things are different to when I started, it used to be that browsers were a viewer only. but now they run an application sandbox

@staticvoid (https://discordapp.com/channels/634104110131445811/634374616646811648/634477993133342730)

Ok I see the validity of that argument, but still, HTML, CSS and JS have well-defined purposes to this day and web applications work much better when separation of concern (w.r.t these purposes) is respected.

Take AngularJS for instance. Sure, it works. I use a couple of sites made on it.

But I don’t enjoy using them. It’s non-natural from the browser point of view, and they behave “clunkily”

(https://discordapp.com/channels/634104110131445811/634374616646811648/634478976781516802)

6 Likes

Keeping a bit off the original topic but for good reason, I should also point out that this sort of discussion has spawned in Discord a few times (and, I suspect, will continue to), as well as in a few places here in our forums. There is even a closely related thread - Considerations about the tech stack and architecture. If you refer to post #21, I had this to say:

Also adding a relevant quote from @MasonWheeler from I have an SE clone. How do we feel about building on that? :


The older project members voted for/against an SPA approach

And for electing a tech stack:

Again, just to reinforce: Many of the collaborators who voted for C#/ASP.NET Core are (or were) NOT entirely familiar with that stack. The voting, and the decision, was made after very thoughtful discussion in our chat server, where arguments were proposed and evaluated for a few days’ worth.

These were educated decisions (obvious disclaimer, I campaigned for them myself - but that was way before being elected tech lead), and reverting them at this point must be done with at least equal amount of care, if not more (actually, more, for reasons Art has stated).

6 Likes

Just to clear my mind about something I never saw discussed, has the operational experience been taken in account or only the developer side ?

Keeping something live running has its own challenges and the the learning curve is often more steep than for coding.

I’m asking it openly as I’ve seen the point discussed extensively on the code side but not much on the “run” side and I’ve no idea how the team feels about maintaining a live system in .net core, so this may serve as historical data on this question.

2 Likes

If I have a statically-typed system that declares the type of a function’s arguments etc.

Yes but that’s a false dichotomy IMO.

Because when I tried my “prototype of StackOverflow using React.js”, then I used TypeScript rather than JavaScript.

It’s compatible with and compiles to JavaScript – and I like it much better than JavaScript (also better than using Google’s closure compiler)

  • For defining the signatures of functions and especially during any refactoring (e.g. during incremental development)
  • For defining data i.e. the elements of an object (an object type or interface, e.g. to define what page data elements are retrieved via an API, i.e. the input data to the rendering code which creates the DOM).

The debugger is widely acclaimed and the IDE offers more-than-decent refactoring tools.

I used VS Code (with Google Chrome), the “debugging” experience seemed to me perfect – and the IntelliSence. There’s even no explicit compile step IIRC, the compiler and loader are doing automatic incremental compilation and reloading, so it’s immersive (and the VS Code UI isn’t too cluttered but is full-featured and quick, I like that too).

Another benefit (of JSON plus client-side rendering) is integrating the code which updates the page when an update is received (pushed from the server), which is necessarily on the client, with the code which creates the page in the first place.

Your (i.e. “you” plural) other objection here to JSON plus client-side rendering was wanting to support browsers whose users have disabled JavaScript. A potential fix for that was “universal” code which runs the same code-base on the server and/or in the client. And running a browser without JavaScript seems to me for luddites anyway (and perhaps some of the dumber bots too), and the UI they want is simpler (like “static” HTML, maybe fewer links, maybe read-only access to the site).

Aaah, so you are ChrisW on Discord. I had a hard time trying to find that implementation you did, but now I got it.

Valid point there and I certainly agree with you on TypeScript.

I used VS Code (with Google Chrome), the “debugging” experience seemed to me perfect – and the IntelliSence. There’s even no explicit compile step IIRC, the compiler and loader are doing automatic incremental compilation and reloading, so it’s immersive (and the VS Code UI isn’t too cluttered but is full-featured and quick, I like that too).

I haven’t, but great to know the experience is seamless. Might try it sometime. That aside, and in any case, I’ve yet to find anything that comes even close to the VS 2017/2019 C# debugger. Even more so with IntelliTrace and now this new feature called Time Travel Debugging, but these are luxury available only in the Enterprise edition so I don’t get to use them day-to-day.

(…) A potential fix for that was “universal” code which runs the same code-base on the server and/or in the client. (…)

I remember @DoctorJones proposing the same idea! Not sure if here or on Discord.

2 Likes

It was here, and here. I wasn’t really proposing it, just explaining the concept. Although I do think isomorphic rendering is highly desirable, the point is moot if we’re not developing a SPA.

1 Like

IIRC I did something like this – https://www.google.com/search?q=create-react-app+typescript

Some of the magic is in CRA, reloading into the browser when the source is changed, and some of it is in VS Code, incrementally recompiling when the TypeScript is edited.

Cool. Well I was wondering how they made that fast enough – then I read, “You can expect about a 10x-20x performance hit in typical recording scenarios”, so perhaps that explains that.

Some software I wrote previously couldn’t support a debugger – hard-real time, live systems, and embedded systems. I do like a type-safe language, so “debugging” happens before the software is run (not to mention logs).

There’s an apocryphal story, of Richard the Lion Heart’s comparing swords with Saladin – the English king in all his armour demonstrates that his sword can break an iron bar – to which, Saladin tosses a bit of silk in the air, and slices that in two with his sword.

The debugging with VS Code (of code running in the browser) seemed good enough – like Chrome’s built-debugger (which VS Code was presumably using, headless), breakpoints and the call stack and watching variables – except happening in the VS Code window, and mapped to the TypeScript source code.

And I found it’ll do, for debugging Node.js code too.

1 Like