shroompasta

I've read The Molecule of More and didn't consider it all too great of a read.

There were some correlations that didn't sit well with me - one, off the top of my head, was an implication that MDMA consumption could make me politically conservative.

I personally would recommend just Huberman as he covers Dopamine to a great extent.

I'm not sure there's a good distinction between web apps or websites today.

Would you consider Instagram or Twitter a website or a web app?

If I type 'IG ${username}' or 'Twitter ${username}' or '@${username}' in a search engine, you should expect what is to be expected within the first result.

SEO is important for web apps, how do canvas based applications deal with that.

If React Native is good enough for Discord, it's good enough for a lion's share of applications out there.

If you're dealing with any complex architecture, there will be portions of your service that will be hit more than others.

I'm currently building a backend in which will need real time capabilities and also standard restful http services.

Separating the real time service which will need a significant amount of performance more than the restful services will help me better scale.

Furthermore, the entire backend is written in python, because that is what I'm currently capable of at the moment, but in the future, migrating the real time service to Go will be heavily favorable - by separating it into its own service allows for that rewrite to happen at ease.

Now, there are many cases where building microservices are an overkill, but this isn't a one size fits all approach as the author would suggest, and I think we should all be tired of hearing a this or that type of article.

It isn't "misperceived", they are actually harmed when adjusting for their SAT scores and academic records.

I don't understand how if you're on a team in which you control both the front end and back end, you wouldn't understand these factors - "Will the server send IDs as ints or strings? Will it accept either? Which params are optional? What shape does the data come back in, an array of results, or an objects with results nested somewhere? etc"

Surely you would know all the answers to these questions because your team control the entire stack.

If it was the case that the FE and BE teams were separate, then these would be reasonable considerations, but I just don't see it in a team dealing with full control.

The problem with GraphQL is on the front end. Suddenly, the FE team becomes responsible for understanding the entire data model, which resources can be joined together, by what keys, and what is actually performant vs what isn't.

Instead of doing a simple GET /a/b/1/c and presenting that data structure, they now need to define a query, think about what resources to pull into that query etc. If the query ends up being slow, they have to understand why and work on more complex changes than simply asking the BE team for a smaller response with a few query params.

I hit this problem when contemplating exposing the API of the application I work on to customers, to be used in their automation scripts.

We quickly realized that expecting them to learn our data model and how to use it efficiently would be much more complicated than exposing every plausible use-case explicitly. We could do this on the "API front-end" by building a set of high-level utilities that would embed the GraphQL queries, but that would essentially double much of the work being done in the front-end (and more than double if some customers want to use Python scripting while others want JS and others want TCL or Perl).

So, we decided that the best place to expose those high-level abstractions is exactly the REST API, where it is maximally re-usable.

As someone who is relatively young, these "over-complications" have been the norm for me, which is one the reasons why I find it difficult to relate to HN especially in the development of web apps.

HN's perspective on FE Development is that it should be a meager skill that can be on-boarded with ease, and there is frustration with frameworks (most notably, React), because what was once done with HTML/CSS and a sprinkle of JQuery has exploded into an actual field and specialization.

And, personally, I think it's warranted.

The explosion in demand for what the front end requires is just in correlation with the specialization of the field.

15 years ago, we were just doing blog posts with form submissions, now, we're trying to pave the way so that applications like Photoshop can be accessible in the web.

HN is getting old. There's no doubt about it.

And the young ones are starting to lap you guys.

I just hope I don't grow as bitter and hostile when my brain no longer can pick up new esoteric material with ease as some of ya'll.

I disagree.

How would you be able to validate data that you can map to your tables without hitting the db?

If you wanted to add a new row of data to one of your tables, you would have to hit the db, get row columns and make sure that data fits.

Or you could write out your table structure separately outside of the db, and validate against that, but that would just leave you with two sources of truth which is an antipattern.

Or you could just use an ORM.

I'm fluent in SQL, and understand the solutions that ORMs solve - it's not just a pure abstraction over sql queries, but the tooling and utility provided wrapping around that is what makes it so powerful.

I found it significantly easier to set up table structures and migrations through ORMs and abstractions as opposed to raw sql scripts.

Moreover, many ORMs give you the tooling to validate data before hitting the db, which is also another huge plus.

I mainly work with Python on the backend, and I've recently switched from SQLAlchemy + marshmallow + alembic to SQLModel and both have been amazing to work with.

I would never dream of setting up tables through plain raw sql ever again.

If it is the case that I'm moving onto a different language, as Go may be it, I'm willing to learn the ORM, granted that it deals with migrations and validations out of the box.

i'm interested in the engineering behind this. is this kepler-gl? looks very uber

It's a case by case scenario.

I built my project in a microservice architecture, so when the author states that microservices were built so that teams can enjoy their independence, it doesn't apply to me as I am currently a 1 man team.

I split my services up for many reasons, but primarily two, the ease of migrating from python to go as the ease of rebuilding one service at a time differs as opposed to a full blown rebuild, and also for performance and scaling as parts of my application will be hit harder by outside requests than others.

>Web requests can be managed by one type of instance, that results in one EC2 image or whatever. Anything that can be handled within the lifecycle of one request can be handled there, and these instances are horizontally scaled behind a load balancer.

The author gave an extremely simple and generic system design, and while this can work for a sizable amount of applications, there are still a significant amount of applications that require and demand a more complicated structure.

One of the services that I have split, almost exclusively deals with real time connectivity with websockets which requires a towering amount of performance as opposed to the other services that I have - to place these in a monolithic structure, scaling would be incredibly awkward - imagine adding 10 more load balanced boxes just so you can handle your websocket requests, but now the part of your app that deals with all your http requests is now also horizontally scaled when it didn't need to be.

>On the communications front, internal web services are often doubly inefficient by using REST rather than binary transmissions. There’s no reason for any of this, and if multiple microservices hops are used, this all adds up and slows down the system. Even just a conversion to JSON and back is a wasted effort, more so if done dozens of times.

This is true - while initially developing internal communication with GRPC, I've reverted back to http despite the 30-50ms TLS/SSL handshake simply because its a tired and true technology.

GRPC is still relatively new, with seemingly insubstantial development, and I was afraid to proceed further as roadblocks and technical debt may be accumulated in the future.

However, in a smaller mesh, in my opinion, anything shorter than ~150ms is insubstantial in my opinion - A blink of an eye is just about 150ms, and if it is the case that the internal requests are hitting multiple endpoints before resolving the original request, then it's more of an architectural problem, not that "microservices" are a problem.

Not everything has to be finely chopped, but breaking some portions down can make it more digestible

>The result was a new component we called <FastList>. The team intends to merge these together for cross-platform use and open source it for the community. With that we removed a lot of memory allocations and were down another 70-90ms of render time. We could now scroll the channel members list as fast as we wanted and it kept up admirably.

https://gist.github.com/vishnevskiy/f4ba74adf5cf1d269b860fab...

This is FastList Code. it's 100% javascript, and only imports are lodash, react, and react-native

That was their initial problem. Upon further reading, you will find that they found a solution in dealing with Lists with React Native. My initial comment had the answer - they brought in a component that visualizes lists from their web platform, and it worked seamlessly in React Native.

So no, while they initially implemented their core chat view natively, they are using full blown react native as of right now.

this article suggests otherwise.

https://discord.com/blog/how-discord-achieves-native-ios-per...

> At first, we felt that maybe doing it purely in JavaScript was futile. We spent some time trying to glue together UITableView with React Native, and while we made meaningful progress, it started feeling overly complicated. After stepping back and thinking about what else we could do — it hit us. We already solved this problem once before on the web! We already had an internal List component that virtualizes its children. There is no way we could just drop it into React Native right?

I'm also curious why it took them so many pain points to reach list virtualization as their solution. That would've been my first thought.

I'm curious as I think I'll be making this decision in the near future.

> it's more likely that you'll want custom UI (animations, transitions, etc) and functionality that require full access to native APIs.

Besides the custom UI stuff, as I think React Native has some decent animation support nowadays, what specific native APIs were needed in Substack's case that made React Native an ineligible choice?

As text being the main content for Substack, Its hard for me to imagine why React Native wouldn't be sufficient for a relatively simple app.

Discord, undoubtedly, has more complex UI needs compared to Substack, however it's humming along just fine with React Native.

What makes React Native capable for Discord, but incapable for your needs?

I follow quite of bit of celeb news, and I really don't understand the stardom of this dude.

For those who don't know, Kim Kardashian getting with Pete Davidson has sent Kanye West through an appalling emotional episode, with absolutely no restraint on publicly sharing his animosity towards Pete.

Just today Kanye posted a music video of him kidnapping, burying neck deep, and decapitating Pete Davidson.

It's just weird to me how someone like him is in the spotlight (or crosshairs) as a mediocre comedian.

Every time I see him in headlines, it's always about who he's dating or who he's having dinner with. Never is it about his own work.

I don't get it.

not practical for hiring.

and although I find it intriguing that hey.com is using Hotwire, it's still insignificant compared to some SPA framework's ecosystems.

Performance isn't an end all be all, otherwise we should make another article and say "Python and PHP was a mistake for web servers"

There is some give to be had for the sake of practicality.

Even if that is the case, is that your demographic?

Are those the people calling for an uber?

Are those people ordering off of doordash?

Furthermore, code splitting / lazy loading is available on many SPA frameworks so you don't have to download all the Javascript in one go.

I mean, of course the co-creator of Django would say this.

I wouldn't recommend newer generation of developers to build traditional web apps, let alone use jQuery.

I don't understand why people think we're still in the age of form submissions and blog posts - There has to be a good majority of us here that has worked on something complex that required SPAs here, no?

Not only would it be detrimental to a young developer's career to suggest avoiding SPAs in regards to hiring, but only limiting that developer to create blog post styled content is severely restraining.

Let them develop their blogs in SPAs, at least when they are needed to go into something a bit more complex, they at least have the foundational knowledge required to move towards that.

What you're suggesting is to learn two things, (one that is inevitably being phased out), and spend the mental effort to discern when to use either one, when the more beneficial alternative is to learn SPAs and just go with it.

No 18-25 year old is trying to make a Weblog where walls of text is the main content - Youtube shorts, instagram reels, tiktoks and all these bite sized content has done a great job at destroying that level of attention span.

They're going to be building something else, something quick and visual, something pleasing to the eyes - and more often than not, it's going to require a SPA.

It's posts like these where I can feel the age of HN.

For many developers, especially in startups, SPAs are all they've ever known.

Now, I'm relatively young, but I'm old enough to know monolithic django before moving onto angular then onto react, and it is quite staggering what I'm capable of doing in SPAs as opposed to traditional web pages.

You mentioned Soundcloud and Youtube, but you'd be lying to yourself if you think the list comes even close to even stopping there.

How about fantasy drafts in DraftKings, Sleeper, or FanDuel?

How about chess like chess.com or lichess?

How about collab tools like Trello, Monday, or Asana?

I wouldn't even dream of building these types of applications in a traditional web app

The level of interactivity that is capable within SPAs makes applications like these seamless and snappy, and overall feel-good for the user.

I would replace 'Boring' with 'Tried and True'.

I was going to question the cost of an 'innovation token' for MongoDb and NodeJS, but I realized just now that this article was written in 2015.

For every greenfield project that I came to build, I always gave considerable thought to finally using GraphQL as opposed to REST, just for the hype and growth.

Don't get me wrong, I understand the use-cases of GQL, especially in the context of multiple types of clients that don't obtain the same responses, but my appetite and longing to use GQL was always because the guy next door was using it and I didn't want to get left behind.

Furthermore, it's not like I can't implement some form of 'data shaving' through query params or detecting mobile / pc through user agent, or just simply adding another endpoint (or a couple), which basically solves what GQL has to offer.

That being said, I always went back to REST because it just worked - a request to and endpoint which hit the db, was simple, tried, and true.

A lot of new technologies nowadays are solving problems that we didn't know we had, and a lot of it is due to hype with young engineers catching the wave simply because it's got a classy and fashionable looking landing page, when really the favorable solution is the tried and true tech.

But hey, sometimes the wave does build, and sometimes, we do have to get on board or get left behind.

a simple architecture

json data => python server => redis

- json data gets serialized from json to string in the python server

- python server then stores that string in redis

to request from python server

- string is retrieved from redis server

- string is deserialized to send response as json

the Web client is in Javascript

JSON is native to Javascript

it is already readable to the client, there is no deserializing that needs to happen.

clients don't deserialize json.

object graphs should be just called json or response body; you shouldn't use all these unorthodox terms.

a failure will be caught if a 400 was sent. This is how axios works - if you try a request, a 400 will automatically hit the catch.

a better designed system would be specificity. 75-90% of the time you're most likely going to look at the error body anyways.

1. You don't need to learn macros for VSCode. I personally use just about a dozen of them, but the mouse suffices for majority of the usecases. I don't have the necessity to shave off milliseconds.

2. Vim requires 2-3 dozens of keybindings memorized in order to have a decent feel for the editor, which of 1-2 hours of daily practice took me about 2 months.

3. The productivity gained from keybindings/macros/file navigation is negligible in the bigger scheme of things as it is your brain that does the heavy lifting in code.

No we won't.

We have a standardized way of dealing with errors in which we will send 400/500

and have an error.data.err and an error.data.message in which err will give a title of the error, and the message elaborating the error in all of our errors across our APIs

the reason being is we don't need our developers to memorize dozens of generic status codes, and can be extremely specific in our error.data.err in which status codes can't.

It has worked for Facebook, It will work for us.

But you're already doing this for actual non-error responses...

I'm currently dealing with an endpoint where it sends anywhere from 2-4mb worth of JSON data. Do I expect my clients to traverse every key and every deeply nested field to find what they're expecting for?

Absolutely not. because there's an internally standardized way of dealing with things and that is also precisely how we also deal with errors.

Now if you have an external API that faces many clients that you don't know about, then maybe there is consideration for usage of specific status codes.

But even then, your api should have documentation for it.

I"m sorry, i'm not seeing the difference

how is

if error.response.status === 429 // then do something

different than

if error.response.data.err === 'RATE_LIMITED' // then do something

Also, do you mean to tell me that you've never had to elaborate on your error messages and just sent back status codes with no body?

I'm sorry but that does not sound like a robust API to me.

90% of my error responses have specified data, and I have to check the response body extremely often regardless of the status code being sent back.

APIs should be giving back specified error messages regardless as 4xx and 5xx errors can still be too generic.

For example, if you're rate limited (429), a robust API will still give you back data on how many requests you've made and how many requests you're allowed to make, so you're still going to have to check the payload regardless.

The combination of specific error status codes along with error messages has been redundant in my experience.

Furthermore, in Axios, checking for `error.response.data` isn't terribly far from `error.response.status`, so I'm unsure of this "worst client experience" you're talking about.

It's pretty intuitive for me.