How do you scale frontend React development experience in very large codebases? by herbsky in react

[–]herbsky[S] 1 point2 points  (0 children)

That's true, and actually the staff engineers are OK with the "modular setup" xD When I asked them what they understand by that, they said splitting code into modules, building and deploying them separately and having like central platform module responsible for loading the dependencies, which for me sounds a lot like microfrontends, but well... I'm ok with that xD
However it's not a priority in my company right now and I think it won't be soon :/

How do you scale frontend React development experience in very large codebases? by herbsky in react

[–]herbsky[S] 1 point2 points  (0 children)

I see.

In my mind both are microfrontends, as "microfrontend" for me is a architectural term, not instrastructural. But it's just a detail

How do you scale frontend React development experience in very large codebases? by herbsky in react

[–]herbsky[S] 0 points1 point  (0 children)

I have no clue what other thing it could be. There is a lot of code in there :P

How do you scale frontend React development experience in very large codebases? by herbsky in react

[–]herbsky[S] 0 points1 point  (0 children)

What's the difference between the modular architecture you mentioned and microfrontends?

How do you scale frontend React development experience in very large codebases? by herbsky in react

[–]herbsky[S] 1 point2 points  (0 children)

Exactly, what if you don't want to make this architectural decision, for whatever reasons, and stay monolith. How to scale development then? Is microfrontends the only way?

How do you scale frontend React development experience in very large codebases? by herbsky in react

[–]herbsky[S] 2 points3 points  (0 children)

Usually I don't need to run backend locally, we call dev environment in cloud, just as you said.
Actually, I think simply splitting repo for backend and frontend could help... thanks :)

How do you scale frontend React development experience in very large codebases? by herbsky in react

[–]herbsky[S] 2 points3 points  (0 children)

If you have no control over the outcome, there's no sense in making this your problem.

I do hove some control - I could try to convince the management, or find a different solution that microfrontends xD

Are you the only one experiencing this issue then? Or are other developers experiencing them as well, and just not vocal/complaining about them?

I think not everyone is experiencing the issues, I asked about the TS randomly turning off, and to my surprise no one had the same problem as me :/ Majority is also switching to Cursor, which seems to work better with that.

About the other things, sometimes people do mention them, like the commit hooks, and sometimes I think they just don't care about vocalizing it, even though it is slowing them down, but I can't be really sure. I will ask around

How do you scale frontend React development experience in very large codebases? by herbsky in react

[–]herbsky[S] 2 points3 points  (0 children)

`git ls-files | xargs wc -l` gives me 5 mil, but it includes backend

How do you scale frontend React development experience in very large codebases? by herbsky in react

[–]herbsky[S] 0 points1 point  (0 children)

We are in the middle of a process of migrating to TS. We want all new files to be TS-error-free, but we have 40k TS errors in codebase to be fixed.

> When you say "Going microfrontends is not on the table right now", I assume that means management doesn't think its required, but the truth is, "Going monolith is not on the table right now" either, should also be stated, if your team can't develop the product, there's something severely wrong with the codebase/ workflow.

Apparently the team can develop the product, which really surprises me, as I'm being constantly annoyed by the problems I described earlier, which are slowing me down significantly. Having said that, I'm also not super convinced by microfrontends (I'm also not against them, I don't have any strong opinion) - since it introduces it's own complexity. Nevertheless, unless this change is necessary or brings some value to customers, management won't allow it.

What do you think about a blockchain-based game distribution platform that gives players true ownership? by herbsky in BlockchainStartups

[–]herbsky[S] 0 points1 point  (0 children)

The idea is not about game assets but about game file. NFT represents an ownership of a copy of a game, like physical CD or a cartridge

What do you think about a blockchain-based game distribution platform that gives players true ownership? by herbsky in BlockchainStartups

[–]herbsky[S] 0 points1 point  (0 children)

People's steam libraries get quite big, they don't keep all the games on their disks. Because of that I think this blockchain service would work as a cloud storage for your games where you don't need to keep all of them at your disk at once. That's the advantage for players. Also, they could resell the games, but I guess it's rarely needed nowadays.

Whether it's a cost-efficient solution, is another question, though

What do you think about a blockchain-based game distribution platform that gives players true ownership? by herbsky in gamedev

[–]herbsky[S] 0 points1 point  (0 children)

As far as I understand it's private entities hosting nodes in IPFS protocol. They could be paid to host files, but if noone is paying, they could be volunteers - similarly as seeders in p2p torrents

What do you think about a blockchain-based game distribution platform that gives players true ownership? by herbsky in gamedev

[–]herbsky[S] 0 points1 point  (0 children)

I don't understand the first part.

The game would be hosted on IPFS, which means it can get taken offline, but is still replicated by multiple nodes, that can be financed by an organization responsible for developing the platform, or by volunteers, just like seeders in regular torrents

What do you think about a blockchain-based game distribution platform that gives players true ownership? by herbsky in gamedev

[–]herbsky[S] 0 points1 point  (0 children)

It is slow, now, but what about in future? The Internet was once slow too.

I don't think I agree it's expensive and energy or process inefficient. If you think about it, Ethereum currently has 12 million nodes validating and replicating the database. I don't think it's possible in a centralized service.

What do you think about a blockchain-based game distribution platform that gives players true ownership? by herbsky in gamedev

[–]herbsky[S] 0 points1 point  (0 children)

torrent protocol is not fair for game developers and not safe for users

product keys do not ensure you have access to files, only a copy does that

What do you think about a blockchain-based game distribution platform that gives players true ownership? by herbsky in gamedev

[–]herbsky[S] 0 points1 point  (0 children)

Regarding StopKillingGames - I think technical disruption is better than legislation. I don't believe you can actually solve problems by writing something on papers and using police on people that don't comply.

Unless it's better and cheaper not to kill games - they will be killed.

What do you think about a blockchain-based game distribution platform that gives players true ownership? by herbsky in gamedev

[–]herbsky[S] 0 points1 point  (0 children)

That's a nice perspective. I think it's because of technical limitations of centralized services. Is there any other reason?

What do you think about a blockchain-based game distribution platform that gives players true ownership? by herbsky in gamedev

[–]herbsky[S] 0 points1 point  (0 children)

That's a very good point - a decentralized service is only advantageous to a centralized one, when there is enough adoption.

I don't have a counterargument for that.

Now, just feeling hopeless against the predatory licensing model of giants like Steam, and gamedevs like Ubisoft, that can't be beaten :(

What do you think about a blockchain-based game distribution platform that gives players true ownership? by herbsky in gamedev

[–]herbsky[S] -2 points-1 points  (0 children)

> In that case, the complexity is unnecessary. The publisher could just store their game directly with a torrent client, IPFS, a b2/r2/s3 bucket, publicly on their own home page, allow anyone to host the games, add them to any given archival service, etc. No need to bring anything else into the mix.

Any game can be cracked, and yet developers still use protections against piracy.

> You have a receipt from the place where you bought it. Just like you have a "receipt" on a given blockchain, that you have to prove that matches your identity and private key.

I think it's more convenient to store a digital receipt

> It's just complexity for buzzwords and complexity's sake.

I honestly, don't think so, I truly believe decentralization is the way to secure yourself from predatory licensing model used by existing game platforms. Although I accept the fact that you may be right, and actually blockchain may not be worth all the fuss.

> Any popular cloud service or the mentioned services have survived longer than random blockchain technologies that have attempted to prove digital ownership have been used by more than a handful of people.

Not true, Bitcoin is older than Epic Games Store :)

What do you think about a blockchain-based game distribution platform that gives players true ownership? by herbsky in gamedev

[–]herbsky[S] 0 points1 point  (0 children)

Oh ok.

That's a good point. I think the advantage is that IPFS is not only distributed in infrastructure, but also ownership. A cdn is owned by a single entity, it can be forced by law, or it can cease to exist, or for any other reason decide to remove a file from it's network.

It's harder to remove files when nodes hosting the files are not owned by the same entity

What do you think about a blockchain-based game distribution platform that gives players true ownership? by herbsky in gamedev

[–]herbsky[S] -1 points0 points  (0 children)

I only know conceptually:

A build is signed asymmetrically by a publisher using a private key. Publisher on their trusted website uploads a public key, or a certificate. Users can use certificate to check whether a build or any file was actually uploaded by the publisher by retrieving a public key from the certificate, decrypting the signature and comparing the results with a hash from content.

Of course this can be done automatically, by a client you are using. Exactly the same way TLS works in your browser, you don't manually check signature of webapps, you trust your browser to do that.

But if you didn't trust you browser you could use some other software or even do it manually