agconti
Joined 12 years ago
Joined 12 years ago
Andrew here (https://www.linkedin.com/in/agconti/). I'm the founder of Reactive Streaming, (https://www.reactive-streaming.com), a platform as a service that enables product and growth teams to create interactive live experiences through our easy to use APIs. We make it easy for you to build a live experience by taking care of the foundational live streaming technical challenges so you can focus on what differentiates your product.
- we have the fastest live video in the market, thanks to our propriety live streaming process.
- our interaction services, (a BAAS), lets you create deeply engaging visceral experiences with ease.
Want the skinny on what we offer? Here is a video: https://www.reactive-streaming.com/product-demo/
I'm located in NYC and I'm looking for a co-founder with deep sales and marketing experience. If you're interested, please reach out to me on LinkedIn!
ie.
Their approach in accounts models.py:
https://github.com/saasitive/django-react-boilerplate/blob/m...
Over the standard approach in their notes models.py:
https://github.com/saasitive/django-react-boilerplate/blob/m...
( Maybe surprisingly? ) This is type of query is natively supported by Postgres. That support is robust and mature, you don’t have to hack it together.
ES is a great tool and it’s clear your a fan of it. If you’re interested, I’d recommend you look into Postgres capabilities. It’s not a replacement for ES by any means ( or even a competitor to in my opinion; Postgres isn’t even distributed ). But for specific use cases, you might find that Postgres capabilities surprise you!
You might be able to get away with if if you were indexing a less then large amount of very small documents.
I like your expression index idea a lot.
You could lean on the relevancy strategies built in to ES, but in my experience you're better off understanding what relevancy means for your dataset and implementing a strategy yourself. Your millage may vary though, I'd never advocate reimplenting something that's already provided by your chosen tool.
The options and tools for configuring and tweaking relevancy between ES and PostgreSQL's FTS are surprisingly similar for many application use cases. If you're interested you can check out Postgres' search rank and query weighting configurations.
- Using a `SearchVectorField` is a must after 500K rows.
- Make keeping this field up to date easy for yourself by populating it using `SeachVector` with a Django pre_save signal or PostgreSQL trigger. This reduces CPU utilization significantly as the parsing and tokenization of the field your searching on is done a head of time.
- Adding a GIN Index on your `SearchVectorField` column will improve performance dramatically.
- You should specify your language configuration for postgres FTS parser. The default parser doesn't do much. It just removes spaces and normalize case. Specifying a language lets the parser make heavier optimizations that noticeably improve performance and the quality of results. If you need support for more then one langue, Django already makes it easy for this configuration to be dynamic.
I just finished a a project where we chose Postgres's FTS over using Elastic Search. At the beginning, I was worried about what performance we'd see since we choose to not use ES. But after slight performance tweaking, we had even our least performing queries under 50ms.
Your recommendations look great, especially libclould.
What do you think can be beefed up in getting started docs? Getting setup on your laptop should be as simple as cookiecutting your app and running `docker-compose up`. Is there something missing that you’d like to see documentation about?
I agree with feedback about Heroku. Professionally, I use Kubernetes and I’m looking forward to when amazon’s managed kubernetes service is out of developer preview so this project can use it. I’ve kept with Heroku because its such a nice platform to get an app started on. It allows you to rapidly develop your app from 0 to 1 without being over encumbered by infrastructure concerns before you need to be. I’ve also kept it in because the integration is just pushing to a docker repository. Just changing the repository destination gives you continuous deployment to anywhere. I like that its flexible and doesn't lock you into a vendor.
Would you rather have continuous deployment to Heroku removed then included?
I’m the creator of cookiecutter-django-rest. I’m super happy to share this release with you. This is a big one.
What api frameworks do you use?
What kind of enhancements are you looking for?
@agconti
https://github.com/agconti