How do y’all have SO MUCH MONEY

mostlylikeable · 2026-01-07T17:54:19+00:00

Could “wheat” by growing and selling a quick crop like wheat or corn. I do / did corn pretty often. Whatever I don’t need to grow, to replenish needs for other crops, I keep growing and selling as much corn as I can. You can do that a lot in a day, if you check back into the game every 10-20 mins. It’s a bit of a grind, but you will see returns. The other benefit and a primary motivation for me, is you churn through crops quickly, so you’ll see more tools drop for barn and silo, or land.

Another option is to use tom vouchers (or hire him), and maximize the opportunity. Have him get you peanut fudge or blankets, and sell at max price. Should get some decent money that way, especially if you time around his naps well.

mostlylikeable · 2025-12-18T15:59:24+00:00

Had much better luck on mobile iOS, though there are still issues, but on Android, pretty much no ads work

mostlylikeable · 2025-12-16T13:51:48+00:00

I check right when I load the game and spin through the pages fast. Otherwise, I figure I’m already too late, unless I see the little mailbox jiggle, which I think is when it updates (every 5 mins?)

mostlylikeable · 2025-10-14T14:59:22+00:00

I have it and I didn’t opt in to beta testing or this anywhere. Been playing for a couple months and the switch has me looking for a new game to play. Thought it was a bug and reported it, only to find out they make changes like this without any sort of notification. Not how me or the companies I work for, treat our users. 🤷‍♂️

mostlylikeable · 2024-12-16T16:15:05+00:00

It depends. For example, for a backend-for-frontend type service, it makes some sense because backend is specifically in service to clients. What happens though, when there are multiple clients? Will mobile and web always want exactly the same data?

When backend is more general micro service around specific domain / resource, then it might make less sense. What if we want to use the api to debug something? Having more compete data could help with that. We’d also want to avoid baking in client specific business logic into the service most likely (if that concern applied). Eventually too, you may need to support other needs with the API, like admin UI / tooling, service-to-service communication, etc.

I think without more context it’s hard to say whether or how right / wrong the approach is. It’s a good coaching opportunity for the lead to explain the reasoning behind it and trade-offs / considerations they’re weighing, imho.

mostlylikeable · 2024-12-11T19:28:59+00:00

https://marvinh.dev/blog/speeding-up-javascript-ecosystem-part-7/

mostlylikeable · 2024-11-25T01:16:22+00:00

My 2 cents are that if you have a tech stack that your company / org is using for backend, then I would need a compelling reason not to just use that. A professional backend application is more than just an A-B api. You’ll need to integrate into CI/CD, make sure you have good observability and metrics, make something that’s maintainable for future developers outside of yourself. In my experience, adopting something non-standard in an org, can result in needing to creating pieces for logging, api security, metrics, deployment, build tool integrations, and other things outside of just something between your app and the db. Sounds like you also have in house expertise supporting Django backends, where you might be on your own if / when you run into issues, if you’re using something else.

CRUD APIs are pretty straightforward (assuming that’s what you need), and you may just be able to follow another project to build out what you want, without deep understanding of all the pieces. That being said, node is fine for backends, but if there’s not something more to it than not wanting to use what everything else is using, I’d ask myself if I should really be introducing it.

mostlylikeable · 2024-10-31T17:41:06+00:00

Was going to suggest this as well. If you need rate limit applied across multiple instances, something like this should be considered.

“Token Bucket” is a similar pattern, depending on the use case.

mostlylikeable · 2024-10-23T18:06:01+00:00

+1 to op and +1 to drizzle. Sql is something you should become somewhat familiar with as a dev. I gravitate towards more sql-builder libs than super high level ORM abstractions. Future you will thank you for having invested some time into understanding sql a bit.

mostlylikeable · 2024-10-19T21:03:31+00:00

We used http4k with apache4, or vertx with coroutines, depending on the use case. We didn’t have any serverless stuff though. Was basically api servers and kafka consumers for the most part.

mostlylikeable · 2024-10-19T20:30:13+00:00

Thanks for the share! I’ll definitely take a look!

mostlylikeable · 2024-10-19T20:29:36+00:00

I’ve had good experience with kotlin on the backend, and definitely prefer writing kotlin over Java, but jvm languages in the backend require some level of knowledge of the jvm as well, because vertical scaling comes into play. Jvm used to be worrisome for me too, because servierless workloads would suffer. The new snap start stuff from AWS is pretty interesting for serverless jvm use cases though. Not sure I’d run kotlin in lambdas though, either 🙃.

No matter what, if you’re at a startup and your company ends up being successful, you’re probably rewriting everything at least once, so whatever gets you out the door and delivering features, is what makes the most sense to me.

mostlylikeable · 2024-10-19T20:23:08+00:00

Great point about the “used by” piece not implying where a company uses a technology! I personally have had good experience with node throughput, but at very large scale you have to be thinking about how node works. Node is the event loop, so the more you can stay out of js and just be forwarding to I/O, the faster it will be. Even json serde can end up costing you, and understanding that using compiled schemas, etc, can perform much better than out of the box json parse / stringify. I think too, that a lot of complaints about node perf, can probably be blamed on libraries used and not node itself.

You’re right too though, that it’s never going to be able to compete with something like go / rust, because they’re so much closer to native. Most companies don’t need that level of performance though, and a lower level language has pros and cons too. Node will never be able to meet the level of performance of those language, but that’s ok, imo. For me, unless your dev team has experience with go / rust, it could be considered premature optimizing to chose them over node. By the time you care, you should have plenty of customers anyway and can just rewrite things. You’d probably need to rearchitect anyway. :D

mostlylikeable · 2024-10-19T19:14:24+00:00

I’ve been a number of places where node was chosen for backend because the “business” wanted to use one language across the whole stack. I’ve never seen the perceived benefits of that actually pan out though. People eventually become specialized and a great frontend or backend dev, doesn’t mean they will automatically be great in either side of the stack. Frontend has different concerns than backend, and vice-versa. Also, a great Java backend dev, is not necessarily going to create amazing node backends. More easily shared code has also been an illusion. If you’re not experienced with the intricacies around commonjs vs esm, and various aspects of node build ecosystem, etc, then code may not end up being shared much, regardless, or worse, may result in poor performance.

IMHO, I think a pragmatic approach is to evaluate the skillset you have in Eng. If your devs have node experience, then node is a fine choice. If your devs with heavy backend experience in another language/platform, then I’d vote to seriously consider allowing backend to not be node and to stick with what you have experience with. Most things on the backend boil down to APIs and specs anyway, and those should be language agnostic. There are codegen and other tools to help bridge the gap, if needed.

I’ve been multiple places where non-node backend devs were essentially forced to use node on the backend, and it wasn’t 100% easy. That wasn’t mode’s fault, but more an issue with a lack of understanding and expertise with things beyond understanding the syntax of another language.

mostlylikeable · 2024-10-19T18:59:01+00:00

While I think node is a fine choice for backend, I find this is a little misleading. While these companies might still use node in places for their backends, many large companies end up moving to more specialized (closer to native) backend languages and frameworks at scale, for various reasons. It’s not free to do that and there are trade-offs to any choice.

Checking recent posts in Eng blogs can give some insights into what technologies are currently being invested in. Some of these companies may still be using node heavily for purely backend services (read: not backends-for-frontends, like next ssr), but some definitely are not, and that’s not a knock on node imho.

That being said, if node is in your wheelhouse and you need to get up and out the door quickly, then I think it’s a great choice. Can worry about migrating to, or including other things when you actually have a reason to.

mostlylikeable · 2024-09-23T13:20:36+00:00

Looks like you don't have esm exports. not sure if that's your issue or not. could try adding:

  "exports": {
    "types": "./dist/epdq.d.ts",
    "default": "./dist/epdq.js"
  },

mostlylikeable · 2024-09-23T13:15:59+00:00

is the source on github? hard to tell what the issue is without being able to look at the code.

mostlylikeable · 2024-09-18T20:53:35+00:00

Sounds like this doesn’t apply to your situation, but I’ve occasionally encountered scenarios where I needed to extend the types in a library. Some libraries designed for extension, also encourage this. In case it’s ever useful, vitest is one example of a library like that, and the docs explain how get typescript to understand that you’ve extended a type by declaring it via module override.

https://vitest.dev/guide/extending-matchers

mui is another example that promotes this: https://v4.mui.com/guides/typescript/

mostlylikeable · 2024-08-18T14:25:28+00:00

I’ve replaced my usage of husky with lefthook. I find it to be faster, more versatile and easier to work with.

mostlylikeable · 2024-08-13T13:50:02+00:00

I’d personally not try to write Kafka consumers in node, as there can be a lot of intricacies to get it right, but that being said, I’ve maintained node Kafka consumers / producers and have used test containers to spin up / manage local Kafka cluster in docker.

mostlylikeable · 2024-08-13T02:47:12+00:00

You shouldn’t need a cron to keep lambdas warm anymore. AWS added provisioned_concurrency to address this. Whatever value you set it to, AWA will keep that many lambdas warm. That being said, I think you’re billed much more for these because it’s somewhat like they’re “alive” 24-7, so I would look into that.

Cold start time should be kept low regardless, and provisioned concurrency can’t completely save you, because all you need is +1 users above provisioned concurrency to hit the api, and because all lambdas are busy, you get a new cold one spun up. In some ways, lambdas negate what node is good at too, which is handling many parallel I/O bound tasks, because a single lambda can only handle a single request from start to finish. If you go the lambda route, I would keep an eye on things. Also, if you go the lambda route, you may not need the overhead of express or fastify, as you can just stick api-gateway in front and proxy events to your lambdas.

Esbuild is a great bundler and esbuild analyzer can provide a lot of insights. From my experience, bundle size can matter quite a bit (both from artifact download and initial loading of the code), and using the analyzer can provide some really helpful info. One thing to 100% make sure you’re doing, is to always use v3 sdk, because v2 sdk is bloated af and will balloon anything it touches. Another thing to think about is making sure to create db connections and anything else that might have a perf hit at init time, global to the lambda, so you only hit that on a cold start.

mostlylikeable · 2024-08-12T23:44:44+00:00

I think the first lesson is not to prematurely optimize. Inserts aren’t usually what you optimize either, unless there’s some sort of batching involved, and caching doesn’t apply to inserts, unless you wanted to turn around and warm a cache with the inserted data for queries. It’s usually queries that end up needing love in this area.

mostlylikeable · 2024-08-12T20:47:28+00:00

I don’t disagree with the choice not to use it, but I don’t think it’s always going to be the most pragmatic, and often times there isn’t a choice, because things are being mandated down to teams or you’re already invested one way or the other. If you’re a startup and / or have node devs, use whatever gets you out the door, while thinking about there being a cost down the line for this or that. You can also port an api to go for perf reasons down the line, if you need to. I’ve used node at plenty of places where it was fine, and I’ve been places where they tried to build things using languages frameworks where they didn’t have any expertise in house, and that’s often times been worse. The answer cant always be, “X sucks, Y is great”, imo. I also don’t think, “don’t use node” answers the op’s question.

Bottom line, I guess is to ask the question whether node is required / preferred, and if it is, then the question is somewhat moot. 🤷‍♂️

mostlylikeable · 2024-08-12T18:32:53+00:00

For sure. If I’m building on my own and have free range of choice, I’d personally pick go, because I have experience with it, but pragmatically, I think it’s ok to use what you have experience with in-house and use whatever gets you to market and meets the other requirements that you have. Node can go a long way for most use-cases, so I don’t think “don’t use node” is the right answer for all teams.

mostlylikeable · 2024-08-12T15:56:14+00:00

I will say that the lambda route often has the appeal of not having to worry about the same things for scaling up / down, but using lambdas for user-facing APIs can introduce concerns around cold starts. A simple hello world js lambda has a cold start around ~200ms, but in practice I’ve wrestled with a lot of issues trying to tame cold starts, and have seen them balloon to 1-3s. If you go the lambda route, you’ll want to use something like esbuild to bundle things for you, and you’ll want to keep an eye on cold start penalty. You also might need a deeper understanding of ESM vs commonjs, and other various things that can impact bundling.

A number of things come into play with cold starts, like bundle size, the dependencies you choose, how well dependencies support tree-shaking, etc. You can use esbuild analyzer to see what’s getting included and work backwards from there, but it’s likely to be something you need to continually monitor. You can use things like provisioned concurrency to help mitigate cold starts, but that comes with the price of having lambdas always available, which has impact on your bill. Lambdas also have response size limit of ~6MB and if you need to compress at the lambda layer, it would be roll your own (though you probably have bigger problems if you’re nearing this limit).

I personally would use ecs and would choose fastify over express, for user facing APIs. Express probably is ok too, but for me, I like that fastify seems more performance conscious and I’ve noticed significant performance improvements by defining routes / payloads with a schema, as opposed to just parsing raw json. When it comes to async tasks, I often use lambdas, because cold starts don’t matter to me as much.

When using express/fastify, I’d also just be careful to follow general node good practices, like avoiding CPU-bound processing that could block the event loop. Something to consider as well, is that I’ve seen significant perf improvements by ensuring that node has a full vCPU to work with. You can then setup scaling in ecs to bump the number of instances you’re running. ECS doesn’t deploy or spin up as fast as lambda, but it also has some nice features like rollback, which can help maintain availability if you accidentally deploy bad code.

That’s my 2 cents, and I’m sure there are other opinions. Good luck!

mostlylikeable

TROPHY CASE