We're a group of makers shipping together. We help each other stay accountable and reach our goals.
Apply for access
Max Makarochkin
@mac_r
i've just checked Tailwind and found it less productive to use. Tachyons organized their documentation in a simpler way. many companies use it. i can't imagine doing frontend without it anymore.
I think perhaps it depends on the level of your css skills, but I find Tailwind's naming scheme to be far more approachable. I also find their documentation to be excellent. Most questions in the slack chat are actually answered with a link to the relevant page. :)
Probably, you already know the noun project. thenounproject.com/search/?q=… Maybe you can find something there.
Use Tachyons! tachyons.io/
How does it compare to Tailwind.css?
i've just checked Tailwind and found it less productive to use. Tachyons organized their documentation in a simpler way. many companies use it. i can't imagine doing frontend without it anymore.
I think perhaps it depends on the level of your css skills, but I find Tailwind's naming scheme to be far more approachable. I also find their documentation to be excellent. Most questions in the slack chat are actually answered with a link to the relevant page. :)
Hey man, let me share one cool trick with you! :) There is no need to move assets to the CDN provider manually. You can do the following. Firstly, deploy everything to heroku and make sure that assets are available. Then you need to get an AWS account and use cloudfront. Cloudfront allows to set up a CDN proxy. You just provide it with a link to your asset path on your website. Then you create a CDN distribution and use it in your html. In order to see local images during development you can set up a switch to local path based on the current environment. The link would switch to localhost locally and to CDN distribution in production.
probably you could combine it with a trello board (cards with jobs and criteria) until you build your own custom solution.
Yeah ahah I've about come to the conclusion it'll probably have to be custom
basecamp.com/ is popular among agencies. bidding system for internal workforce seems to be an overkill.
This agency set up is a little unique, it's more so a scaled outsourced agency, basically owning my own "upwork" except there isn't job posters, I supply the jobs and then if the workforce meets specific criteria or has time they can get the job
probably you could combine it with a trello board (cards with jobs and criteria) until you build your own custom solution.
Yeah ahah I've about come to the conclusion it'll probably have to be custom
Hi Akshay,
"Serverless will scale infinitely, although it has 1 small cost of cold starts but if the site is used regularly then cold start is not needed." - there are solutions that fix it, example: github.com/FidelLimited/serve…
Me and my teammates have been using serverless technologies for a while. This is what we've learned:
1. Running Lambda functions is much cheaper for simple computationally intensive operations.
2. Traditional way of dealing with databases is not a good fit for serverless. Make sure that your DB server is ready to handle hundreds of simultaneous connections. Always close DB connections by the end of each lambda invocation.
3. Use terraform, cloudformation or serverless.js config to set up API endpoints, don't do it manually (otherwise it is a nightmare to set up staging or other envirionments).
4. Long running tasks (like log processing, etc.) are better to do on a server instance.
5. Lambda functions are great for running CRON jobs (using cloudwatch scheduler).
6. Think of a centralized logging solution in advance (Papertrail is a good option).
7. Ideally set up caching with Redis (has unlimited connections) to reduce the load on your DB or consider trying AWS Aurora: aws.amazon.com/rds/aurora/ It's a Postgres compatible solution for the serverless era. Let me know how it goes.
You should think carefully of how to implement authentication properly. The best fit would be using a JWT token.
Tj has recently introduced Up, which helps to deploy serverless websites as well (not only APIs): github.com/apex/up
We prefer having a Heroku instance or a static website running on a server and then using serverless for the API, because the limitation is that you can't use Websocket without a server.
In general, it's definitely fun and cost efficient to build a cloud solution using serverless technologies.
Guys, hit me up on Telegram (@mac_r) if you have any other questions!
Best,
Max
Thank you for such a wonderful answer, Max 👏
Can you answer the question about the app in which I mention the 6 steps above❓
I think its good for Serverless but not sure. Up is very good & I maybe use that or use Serverless Framework.
Also, regarding Databases I read during my Engineering that if 2 people perform the write operation simultaneously then it will probably have a race condition with incorrect values. How to solve that❓ I don't think its a serverless problem but if you can answer that :)
Also, whats the harm in keeping the database open❓Does it have any cost if I keep it open❓
You can implement any service you want fully on serverless unless you need to use Websocket (then you'd need to combine serverless API with a traditional server). To avoid race conditions you can look into transaction locking (ex: in Postgres): stackoverflow.com/questions/4… or you can set flags with a Redis caching layer. The reason why you should always close your DB connections is that functions create a new connection on each invocation. Considering that it's infinitely scalable, we get a bottleneck at the DB level. So your database solution should be ready to handle thousands of connections at the same time.
Thank you 🙌
I have no doubts now & if I have any when I actually build it, I will ask you later on. Thanks Max :)