mark242

I really appreciate the work of getting this up and running; it's certainly a good exercise in making a fully-distributed content site.

What I'm missing is where a collection of static files couldn't just be served up from an S3 bucket and Cloudfront or Cloudflare on the front end -- you arguably have the same caching performance if not better since Amazon and Cloudflare have real SLAs for getting your bits from your bucket to a user's browser.

IPFS seems like un-needed complexity when there are a huge amount of options available. If you personally don't like Amazon, you can use Github pages, or DigitalOcean, or Netlify, or Fastly, or the list goes on and on.

Does anyone have a use for IPFS that isn't already covered by existing hosting+cdn options?

I have the feeling that this will have the same net effect for startups -- or even more -- that Stripe-as-a-payment-gateway also had. This could be an instant accelerator to self-funding.

"Doesn't cost a dime to do this, and not more than 20 minutes of work and 10 minutes downtime from my side."

Your work isn't free. Application downtime is costing you.

Containers that require custom DNS queries about incoming connections from a non-HTTP service (we're using the NLB for this), using a caching DNS server that isn't publicly accessible.

This is big for making services which rely on DNS much easier to roll out in a container environment (ECS, EKS, etc). Traditionally we've had to create custom AMI images, use CloudFormation to keep them running with EIPs, and then have those EIPs be part of runtime configuration for our services.

Have you considered using Aurora Serverless? If you're trying to prove market fit, it can be an order of magnitude cheaper than RDS and you don't have to worry about management in EC2.

The Java SDK for SQS automatically drops >256k messages into an S3 bucket and stores a pointer to the message in SQS itself. You set the bucket and the client transparently handles retrieving a message from SQS/S3 when necessary.

Based on the structure of the message (UUIDv4) you could probably roll your own implementation in any language.

Speaking as someone who runs a commercial antispam SAAS, content filtering is increasingly irrelevant, and isn't nearly as effective as reputation filtering or bayesian classification.

Please don't do this anymore. End-to-end encryption is extremely easy to set up and maintain. P2PE will absolutely lull you into a false sense of security.

This will hopefully prevent malicious sites hosted on v1-style buckets from stealing cookies/localstorage/credentials/etc.

Yes.

I will gladly pay (Amazon|Google|Microsoft|Cloudflare|Zeit) to manage software deployment infrastructure for me, allowing my teams to concentrate on writing business logic. As with any other concept, it has a learning curve, but once you're comfortable with the concepts, your development will speed up, no question about it.

This is what sitemap.xml was made for. You can give hints to all of the engines, and they will duly follow them.

I can't help but think that using the Now framework would have made the author way, way happier. Point now at your Dockerfile, and bam, everything is running in a minute.

Better idea:

  Optional.ofNullable(foo).orElse(new Foo())

Yeah, agree-- the moment that you all get KV to mature to a more Dynamo-like experience with queries and secondary indexes, that opens up a whole ton of possibilities in terms of easily rolling out entire applications that can scale from zero to whatever size.

The more work you can offload to an edge node, the better-- this is a pretty safe general rule to make.

Think of all of the random conditionals that your http routes have; "is the client posting a correct data structure" or "is this a valid OAuth token" or "am I requesting something that I already have cached" or rate limiting or the list goes on and on.

All of that kind of stateless route level logic that may not need to hit a data store is a perfect candidate for an edge worker, because once you have that deployed, you can concentrate more on business logic within your main application.

For example: "I have a valid OAuth token, I have established my identity, now issue an S3 pre-sign request and forward the resulting URL to the browser to download a protected file". Doing that within a worker will absolutely speed up your user experience by a couple hundred milliseconds at least.

1. Go to your nearest finance department, either in the company you're working for or a relative's company, whatever.

2. Find a specific task that they're using Excel to accomplish.

3. Make a web app that reduces their clicks and typing into Excel.

4. Charge whatever you want-- they will pay.

If you are relying on SEO to gain initial traction, your project is going to fail. Start worrying about SEO when you have a core base of users who are actually using your product and by then you'll be more interested in refining features for your userbase that you won't fall into the feng shui trap that is SEO.

edited to add: The reason I discount SEO like this is because SEO is essentially chasing a search result against competitors who likely have more budget, more resources, and more time to play that game. Spend your time on making your product better, aggressively market directly to people instead of relying on the passive results of SEO, and by the time your project takes off, you will hopefully be in a spot where you won't care very much about why using react-helmet doesn't help with Facebook shares.

React hosted in an S3 bucket, API Gateway with one Lambda function per model, single DynamoDB table with overloaded indexes. This will cost you pennies to spin up and get traction with.

Part of the problem is that Twitter encouraged automated signups in the early days, blazing the trail for gigantic bot-farms that we all talk about today. They pushed popular rss-to-tweet gateways, wordpress plugins for auto-tweeting blog posts, etc. There should have been gigantic red flags waving when the hypergrowth of Twitter really started, because you knew these weren't all people signing up for one account.

I'm not sure if Twitter can ever put pandora back in the box, but at the very least, requiring a mobile number is a start. It's hard(-ish) to generate thousands of bots if you have to have a unique phone number with multifactor for each signup.

Email can be made secure, it's just that by default it's insecure and there isn't a Google/Mozilla/Microsoft/Apple conglomerate to penalize SMTP servers by showing "Insecure" in an email display/etc.

* Most mail transport agents can require connections to use TLS, but nobody does because they're afraid of denying incoming messages and because it can be difficult to install a certificate for an MTA, so smaller providers just don't. There should be a LetsEncrypt for mail servers and by default the various package managers and distributions should not install a mail agent that allows non-TLS connections.

* It is possible to store mail messages encrypted at rest, but only by using an encrypted filesystem-- I'm not aware of any MTA that will do this itself. Obviously that needs to change.

* Providers can force TLS connections for IMAP. This is surprisingly easier these days given that most end user mail clients will auto-negotiate these connections.

There's your E2E encryption. This doesn't get you encryption on the final destination, but that's a separate issue.

Two pieces of feedback.

First, tutorials like this should include getting this running using TLS by default. Ideally there shouldn't be any reference to plain http at all.

Second, the DSL for Kube and Ambassador seem ridiculously complex for this. Maybe some explanation for what "imagePullPolicy: IfNotPresent" means? This kind of configuration harkens back to the myriad of Jboss XML files, just in a different format. For me personally, I get all the reasons why you'd want to use k8s, but for a "getting started" user, seeing this kind of required config -- rather than sensible defaults hidden away -- would get very discouraging. ("Why should I learn this DSL instead of just making sure I had a correct puppet setup?")

Yes, it absolutely does matter. Chaining promises together, running them in parallel with Promise.all, and the abortable-promise pattern, make developing (and especially debugging!) much much easier than having to deal with callback hell.

  zam.fadeIn(el, duration)
    .then(zam.ajax(url))
    .then(response => response.json())
    .then(json => el.innerHTML = json.results[2].message)

This code is nearly self-documenting, is easier for a transpiler to handle, and doesn't scream "refactor me!" right after you've deployed your app.

Genuine question: in 2017, why would you create a JS framework that didn't use futures?

eg in the documentation, ".fadeIn(selector, time)" - "Returns nothing". Why not return a future that resolves when the fade completes?

Why would these instances not be behind ELB?

Plus the capex costs of constantly having to buy new hardware and stick it in a datacenter for when your workload went up.

Plus the costs of maintaining that hardware both from an opex and capex point of view.

Plus the capex and opex costs of creating and maintaining the high speed network required to ship those files back and forth within the datacenter space that you're renting.

Plus the massive hit in how nimble your team can be. (Want to support a new codec? Either buy and install new hardware, or set the priority on these re-encodes lower and tell your boss to wait six months)

When you have an extremely variable workload such as Netflix et al, even though AWS/GCP/Azure are more expensive on a unit cost, your savings from operational expenditure will more than make up for that difference. Not having to buy and maintain a bunch of "just using baremetal machines" is a massive, massive cost savings.

Lambda / Google Cloud Functions / Azure Functions are a natural extension of this-- your write/test/deploy cycle can be much, much faster and you don't have to even worry about maintaining any infrastructure. The brainpower savings of this more than make up for the extra cost for CPU cycles.

Combine Cloud9 with a $300 touchscreen Chromebook and that's a hell of an environment vs buying a $2000 Macbook.

Yes. If you're using Elastic Beanstalk, or Cloudformation with autoscaling, Fargate seems to be an incredible waste of money. Maybe if you have an extremely small workload that doesn't need a lot of resources running, I could see it, but at that point you'd be better off with Lambda instead?

> Social Network for Children

Counterpoint-- this should not be built. Kids already have a social network, it's called the playground at school. Having children engage with their friends outside of school time is a fine goal, but there are plenty of existing after-school activities that encourage this interaction. These activities also don't put the undue stress of having to decipher typed language, nuance, and other online-only pressures that adults can barely deal with, much less children.

Get your kids into scouts. Get them into a team sport. Get them into dance. Get them into after-school STEAM activities. Whatever those activities are, that's up to their preferences, but most importantly they are out and engaging with their peers face to face. That "3pm - 6pm" window of time is important for children to play, and having them spend even a portion of that time hitting a like button or whatever other social network validation activities seems extremely disingenuous to me.

He still is. Reamde is a fantastic story of the seedy underbelly of World of Warcraft gold.