agconti

Hey HN!

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!

As someone who works in Django a lot, their non-standard approach to defining models is wild.

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...

Django fits this bill.

That’s cool and I hear you; that’s a complex relevancy definition.

( 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!

The Postgres docs suggest using another column. My guess is that an expression index would be too large if it held the tokenized value of all of your FTS documents. These things can and often are entire written documents. Imagine the index size for 2 Million rows of tokenized documents at 2,000 words each.

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.

I'd argue that relevancy is more your application application's design then the underlying system retrieving the results. For example, putting the same dataset in Postgres or ES wouldn't make one deliver more relevant results given equal configurations.

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.

Absolutely.

- 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 can deeply vouch for the performance and joy of implementing Full-Text Search with PostgreSQL and Django.

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.

My open source project: building best practiced apis fast with Python3 https://github.com/agconti/cookiecutter-django-rest

Hey sheraz — thanks for the feedback!

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?

Hey ya’ll,

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?

cookiecutter-django-rest now supports Django 1.11+!

cookiecutter-django-rest takes care of the details so you can focus on making your api awesome. Scaffolding a project takes seconds and gives you a solid foundation by baking in Django's best practices. Just add your own resources to the api and start shipping.

We're happy to announce that we just released 0.7.0 this morning! We'd love to hear your feedback.

is that you Mark Watney?

> no one can sleep away your exhaustion for you.

This is a really eloquent reminder.

The sites down, here's the cached version: http://webcache.googleusercontent.com/search?q=cache:5fXNOBY...

From the Tao of programming, 1.2:

The Tao gave birth to machine language. Machine language gave birth to the assembler.

The assembler gave birth to the compiler. Now there are ten thousand languages.

Each language has its purpose, however humble. Each language expresses the Yin and Yang of software. Each language has its place within the Tao.

But do not program in COBOL if you can avoid it.

Mike Bostock's talk on visualizing algorithms is one of my favorites: https://vimeo.com/112319901

> Visualizing Algorithms – A look at the use of visualization and animation to understand, explain and debug algorithms.

Startups as investments are very risky with long payoff horizons. With their limited funds, this is a poor investment for the average investor. I can't help but feel like this will hurt more people then it will help.

Evaluating a framework by the number of files its dependencies are broken into is a a pretty poor measure of quality.

Its really awesome that this project continues to endure. The code base is top notch and the maintainers are committed to the highest level of quality.

DRF is one of the core reasons why Django is top choice among web frameworks today. In my opinion, it sets the standard for rest frameworks for the development community at large.

This lib will only work on the latest browsers.

The source leverages calc for simple width percentages, so on android browser below 47 these values won't calculate at all: http://caniuse.com/#feat=calc.

> Partial support in Android Browser 4.4 refers to the browser lacking the ability to multiply and divide values.

Why wouldn't the author change this to:

.Cell.\-1of12 { width: calc(100% * 3 / 12); }

to

.Cell.\-1of12 { width: 25% ; }

It seems silly to go through the trouble of installing a lib when it gives you less browser support than flexbox itself.

cookiecutter-django-rest takes care of the setup and configuration so you can focus on making your api awesome. Scaffolding a project takes seconds and it gives you authentication, user accounts, and the docs and tests to support them. After that, just add your own resources to the api and start shipping.

It also gives you a solid foundation for your api to mature by baking in things like asynchronous queueing, image optimization, and application monitoring.

We're happy to announce that we just released 0.5.0 this morning! We'd love to hear your feedback.

> Like, not having a decent REST abstraction

The community has stepped in here.

Django Rest-framework provides one of the best approaches for creating restful apis that any web framework has to offer. For me, using Django is inseparable from using Django Rest-framework. Its what makes working with Django great.

Nodal by comparison does a lot of great things like Django does, but without the robustness of a rest framework behind it, Nodal seems to have created another good framework but not something new and better.

Working on multiple projects at once on tight deadlines is a great way erode the quality of the development you produce for your clients. I would think with such short deadlines you'd want to give your clients the courtesy of focusing on them individually and then stagger development of your future projects accordingly.