kartickv

Author here.

Fast forward almost a decade

If your system lasted a decade, that's a success, and any startup that just started would love to be in your shoes.

management still doesn't understand the concept of "overwhelming technical debt".

That's a problem with your company, not with the suggestion in my post of adding in layers of abstraction when needed rather than ahead of time.

Author here.

every change to your database will break your client unless they are updated simultaneously every time (impossible for mobile apps)

You can just put up a UI forcing the user to update. Which is perfectly fine since you won't be making backward-incompatible changes to your database every month. Adding a new column doesn't break existing clients.

or your client is aware of every backend change (very complex)

You can just put in a build date in your frontend and compare it against the date a breaking change was made. If it's <, refresh.

Author here.

The article says "build a backend API when it has something to do, not as a pass through to your database."

Author here.

It's good to see a considered response, rather than the typical knee-jerk reactions common on Internet forums including HN.

In this case, I wouldn't disagree with you if you were to do it on the backend.

The article says, "build a backend API when it has something to do, not as a pass through to your database."

It doesn't say "never write any backend code".

Author here.

Your DB is likely to contain internal state that has no business being sent to the client.

Which is why not all tables need to be sent to the client. The post gives an example of exposing the friends table to the client but not others.

If you do this, any business logic not captured in your backend has to be duplicated in each front end.

No, the post says to make your backend layer as thin AS POSSIBLE, not to not have a backend layer at all costs even if it means duplicating code.

How do you make breaking DB changes if you take on this strategy of API design?

You change the frontend!

This advice may be good for a proof of concept, a prototype, or an early version which stands a good chance of getting rewritten.

Which is why the blog post begins by saying, "Say you've started a startup today"

I would not recommend it for anyone wishing to build a lasting architecture.

In a startup, I wouldn't recommend over-designing on day 1, because that's a good way of not delivering enough business value fast enough and so going bust.

Take a look at your favorite famous internet company and look at their API and try to deduce if they follow this advice or not.

As the blog post says, you shouldn't cargo-cult Google or Amazon. You don't operate at their scale, you don't have as much traffic, you don't have as many teams, and so on. You should what makes sense for you given your company's maturity and where in the product lifecycle you are.

Author here.

This article doesn't use the word "permission" or "validation"

The article talks about it multiple times: using a database user account with limited privledges, exposing some tables but not others, exposing read but not write access, giving users access only to data they own.

it's nearly impossible to parse and check an arbitrary SQL query for malicious intent

Which is why the article doesn't propose trying to parse and check queries for malicious intent.

it now passes the responsibility of query performance to the FE engineer. Are appropriate indexes in place? Does the query make inappropriate JOINs?

No, in the proposal, we have backend engineer(s) to advise and assist frontend engineers. Having appropriate indices and JOINs doesn't mean you have a layer that doesn't add business value. And when it does add value, write it!

schema changes now mean that you need to update your front end code. This means guaranteed hard downtime, because you can't control what JS folks are running in the browser.

I don't know if I understood you, but you can just force a refresh in the browser.

you also need to make sure that queries aren't designed to intentionally DoS your DB.

That's a valid point I didn't think of.

There's a lot wrong with the ideas presented here.

It's hard to take your criticism seriously when many of your reactions are a result of your own misunderstanding of the proposal.

Author here:

1. You can't trust the front end. Backends must be written assuming that every call from the front end is malicious.

This is already taken care of in the proposal, by permitting clients to access only data they own.

2. There will be multiple front ends. If all your business logic is in the front end, you'll have to duplicate it into all of them. Where it will rapidly get out of synch and you'll have different behaviours on different clients.

No, because a) not every startup starts on multiple platforms b) you can always put common behavior into a piece that's reused. This can be a library linked in to multiple frontends, or a backend API. The post says your backend should be as thin AS POSSIBLE. It doesn't say you shouldn't have a backend at all costs, even if that means duplicating code.

Forcing your UI to use the same entities as your database.

Nothing prevents you from mapping the entities to different ones for your frontend, in cases where you need that.

The advice in the article strikes me as dangerously sensible-sounding while being mostly wrong.

I don't think you even understood the advice in the first place, as I can see from your misconceptions above.

Not the parent, but I read the book, and the principles have become so common nowadays that I never really had a wow moment. It was more like "Yeah, this guy is telling me things I already know." It is nice to see the common knowledge built up from scratch, rather than just automatically accepted the way it is, but I wouldn't consider the value you get from the book worth the time, today.

8 vs 11 is too small a sample size to say either way. It may very well be that a couple of these startups succeeded due to their business model / luck / sector / whatever which wouldn't apply to the next startup.

If it were 0 vs 11, that would mean something, but 8 vs 11 is too close.

Instead of counting unicorns, we should count the number of successful exits, such as acquisitions. Or, second best, the number of companies that reached (say) series C funding.

the idea that the highest rated films and shows on IMDB represent the "best" of the mediums is kinda silly.

OP here. If you have a better source, use it. Which source is the best was not the point of the article anyway. The point was that you should look for good stuff, not blindly watch the new movie or read the new book.

Thanks for joining the discussion.

It's not about looking back at earlier versions that have shipped and trying to classify them, nor is it about asking someone else. Rather, when there's a disagreement as to whether we can launch what we have, with one side saying, "It's fine to launch, it's an MVP after all" and the other side saying "No it's not at MVP quality yet", take a step back and remember that both sides may mean different things by MVP, as the post says.

Can you configure the camera to take photos till you stop it, or do you have to buy an external device that connects the camera for this?

Author here. Interesting idea.

Is there an Electron alternative that uses the OS's rendering engine (Webkit on macOS, Edge on Windows), for developers who think that bundling a whole browser with their app is not the right tradeoff?

Author here. If you think there's another side to this story, I'd like your views.

Before you can talk about what the key features should be, you should identify what jobs the customer is hiring the product to do. That anchors the discussion; otherwise you'll be talking in a vacuum about whether to build feature X or Y without anchoring it to a job the product needs to do.

The jobs to be done framework too brings the customer into the room. If we're building a photo editor, and I say, "I wouldn't use a feature that makes lips red and removes pimples", then we can talk about the job the photo editor is being hired to do, like "make me look pretty on Instagram". I can put forward my bias like "I don't care about that" and someone can counter that.

Futurecam is a computational photography camera app for iOS that process 1Gb of image data per second on an iPhone 7. It can do things that SLR's can't, like changing shutter speed after capture. Check out http://futurecam.app to find out about more features and how it works. I ran Futurecam as a startup for 3 years and now I'm moving on, so I'm making it open source, under the MIT license. https://github.com/kartickvad/Futurecam

I updated the first sentence to add "or granted a special entitlement by Apple. In either case, that's not how an open platform works."

Even if no entitlement is needed, you shouldn't have to pay a $99 rent to the platform owner to use certain APIs. That wouldn't be an open platform.

Author here. I agree, and I'm typing this from my Windows laptop :)

What about Windows and Linux support? Will it be locked down like iDevices, able to run only Apple's OS?

I think this would be a good thing to try -- hopefully it will remove one barrier to subscription the fear that you'll be paying every month whether you use it or not.

So the way the slider works is that you pay for the max mbps irrespective of data transferred?

At what scale does colocation make sense as opposed to a long-term commitment on AWS or other clouds, where you get a discount?

Funnily, the base model is unlikely to have this problem, which makes it a better laptop (at least in this case) for cheaper. Your script won't stop and lose progress.

I think part of the problem is that school and college teach us to say "no" to something that's not always true. We're told a statement that's mostly true, and asked, "Is this true?" When we say yes, the professor says "No!" While a normal person, one with common sense, would say "Yes". This creates a habit of unnecessary attention to detail, nitpicking, and grasping at straws to come up with some reason why the other side is wrong.

To the extent that the walled garden keeps quality up, I'm all for it as a user, and in agreement with you. I'm all for Apple clamping down on apps that crash, violate privacy, drain the battery, deceptively advertise prices, and so on.

But I don't see how I benefit from some of Apple's moves, such as stealing 30% of developers' revenues [1] when their own apps don't have to suffer this tax, or Apple Music spamming me via push notification ads while others are forbidden from doing so. Or taking down apps that mention that they also support Android. All of these are in Apple's benefit, and against mine.

In 2008, I gave the benefit of doubt to walled gardens. In 2020, it's clear that they need government regulation to stop abusing both users and developers, which a monopolist otherwise tends to do. Walled gardens are still a good idea for people like you and me, but need to be controlled.

[1] When I've already paid through my nose for Apple's overpriced devices.

I agree. I'd think that salaries could keep fluctuating up and down, like in the oil market, rather than the number of people employed in the economy as a whole. After all, better to make 60% of your earlier salary than zero, for most people.

I'd also think that a job may not be worth doing at a given salary but worth doing at a lower salary. Isn't hiring just an ROI decision, which should theoretically make sense at a lower salary?

This is the best explanation I've read about TCP vs UDP in more than two decades!

I like that it describes them in terms of goals ("If you prioritise X over Y, then use..."), not mechanics like stream-oriented.

I wish more technology choices were presented in terms of the fundamental tradeoffs in high-level goals rather than mechanics of the particular abstraction.

Good point.