Swell is a headless, API-first ecommerce platform that many of our users would describe as an a modern alternative to Shopify.
I'm the CEO/co-founder at here, and want to give credit to HN community for giving me a lot of encouragement early on, but in truth this has been a long journey for us to get to a place where we can say, Swell is truly a great alternative to the current "state of the art", which is managing your physical products and subscription products in two different backends. We made a key decision to make subscriptions a native feature, and to make it great, for everyone.
This post marks our announcement of a huge set of features and improvements to subscriptions, including a new headless commerce theme: Horizon (our 2nd one total so far), that will make it easier than ever to launch a beautiful, customizable, and scalable subscription membership site with Swell.
Thanks @tejasmanohar! It's been a great personal journey and now global team effort to get Swell here. For the HN community, what really makes Swell interesting is that it's build on a fully customizable API schema, which enables you to create custom endpoints (content models) that are deeply integrated with all the standard ecommerce functionality you'd expect from a modern SaaS platform. That's what makes Swell fundamentally an infrastructure, and the foundation of the product.
On top of that, we want to make adopting Swell easy and approachable for everyone, not just developers, so we've created a concept called "headless themes" which is a complete store frontend that we host for you, or you can host yourself on Netlify/Vercel. It's essentially a custom app, but works out of the box as an ideal starting point for the long term growth of an ecommerce brand. The key point is that it's integrated with a theme editor/customizer so that admins can control content and other important aspects of their storefront, as enabled by developers. We're standardizing official themes on Vue/Nuxt.js, because we think it's the most accessible and well documented framework, but themes can be built with React or any future framework that comes around.
I think we solved the common issues with REST for Schema (https://schema.io) in a way that makes it really nice for developing web apps. For example, to include related resources you can specify an `expand` field in a get request, and if you want to include unrelated resources you can do it with the `include` field.
There are probably good ways to solve most if not all of the problems people typically run into with REST APIs for web apps, but it could take a lot of experimentation to figure them out. It sure took us a while.
Glad to hear that! For the time being we recommend using the HTTP endpoint with `requests` for python. The official python client will take some time longer because we haven't seen a very big demand for it vs other priorities. However, if anyone is interested in developing it with us, please contact me at eric at schema.io.
We've been using TokuMX for a while and I highly recommend others take a serious look there. It already contains the benefits cited for MongoDB 3 and more. Toku also has a release candidate for the new Mongo storage engine API named TokuMXse, though it's interesting to see that TokuMX proper still outperforms it: http://www.tokutek.com/2015/01/first-tokumxse-performance-nu...
If numbers are the deciding factor for anyone, have a look at TokuMX which I believe has much better performance and storage characteristics compared to plain Mongo.
As the developer of a REST centric ecommerce platform[1], I agree. The price of an order item is specific to that order and does not necessarily match the product's base price. It may be calculated using special account pricing rules, tiered by quantity, or discounted by a coupon. In such a system I have found many occurrences where data has to be de-normalized for this reason. Although the the new state is derived, it may otherwise differ from the source. Not just a function of value and time.
I imagine it has to get much worse before it can get any better. Many Americans view the government as the answer to every problem, and thus continue voting to grant it more power. Nothing can turn the tide except mainstream rejection of the that idea.
We didn't need GEO indexing but what Toku does offer is pretty exciting. Primary wins for us include multi-query transactions, compression, fractal tree indexes (thus overall insert and query performance), and clustering indexes.
Once again, a TokuMX engineer steps up to explain issue and offer a potential solution. I can't help but wonder why MongoDB engineers aren't doing this. But no matter, just glad we're using TokuMX.
Governments create and enforce laws, so they must be held accountable for them. If the government didn't have such discretionary power, lobbying would not be a thing at all.
I don't blame the big cable companies for doing it, since they'd be at a competitive disadvantage otherwise.
Remember that humans operate companies and governments alike. Except governments use force and companies are subject to it.
I need a better introduction to understand how flow programming works, and how I might use it. Instead I see a (seemingly) complex graph which I understand represents a program, but it's not clear how this really works in relation to text programming. I could spend hours and hours digging to figure it out, but that could be a waste of time, so I won't do it.
I get text based programming. Find a way to quickly connect that experience with flow programming, and conversion rate on this site will improve.
TokuMX solves most of the issues you describe without compromising on the query language or other great mongo features. If you are interested in mongo but concerned about these issues, I highly recommend TokuMX.
> in a free market, the customer is supposed to select the supplier, not the other way around
Which free market philosopher expressed this sentiment exactly? None that I'm aware of. Free markets involve free choice of both customers and suppliers. Customers may chose to leave the supplier based on this move, and are absolutely within their right to do so. Customers might even be able to argue their way out of locked contracts.
The idea that free markets should be sort of one-sided, consumer owns supplier, is just silly in my view.
You'd be right except that we also have the ability to create data migrations based on schema changes over time. I'm glad it's not built into MongoDB or else we wouldn't have the (fairly ideal) solution we built to work with it today.
I'm the CEO/co-founder at here, and want to give credit to HN community for giving me a lot of encouragement early on, but in truth this has been a long journey for us to get to a place where we can say, Swell is truly a great alternative to the current "state of the art", which is managing your physical products and subscription products in two different backends. We made a key decision to make subscriptions a native feature, and to make it great, for everyone.
This post marks our announcement of a huge set of features and improvements to subscriptions, including a new headless commerce theme: Horizon (our 2nd one total so far), that will make it easier than ever to launch a beautiful, customizable, and scalable subscription membership site with Swell.
Check it out and let me know what you think :)