I am the CTO of a boutique IT consultancy in NYC. I recently read this book with interest: it exactly matches the tech stack we are helping one of our clients to adopt. I think there are some ways that the book risks turning off or otherwise not attracting an important part of its potential audience: front-end developers.
I apologize if some of the below comes off as a rant. The effort required to write a book of this size and scope is incredible. I applaud the author for doing this.
Old Version of Angular2 The version of Angular2 being shown in the book is 2.1, while the latest version is 2.4.8. I understand that it is hard to keep up with rapid changes, but for a brand-new book I think it is very important to make an effort to upgrade on a regular basis. There are several parts where the author has to write extra code or make a workaround that is obviated by newer versions of Angular2.
No Angular CLI I believe the author misses an opportunity by choosing not to use the Angular CLI to generate the front-end app. Can you imagine writing a Ruby on Rails app without using “rails generate”? The Angular CLI is an amazing feat of engineering, it saves a huge amount of time, and it feels familiar to a Ruby on Rails developer. I am skeptical about the didactic approach of showing a beginner every nuance and detail up front. I believe presenting a large amount of complexity all up front risks turning people off. I personally prefer to show my students or readers the quick and easy way, and then gradually peel back layers of the onion, to show what is really going on underneath and how they can customize it as needed. Angular CLI and Rails CLI both fit that paradigm well.
- The examples in the book look significantly different than those that a beginner is likely to find online when they google for solutions, since the vast majority of Angular2 code uses TypeScript.
Missing Discussion of Trade-offs between Materialized Views vs Caching Tools On page 181 the author discusses Complex Queries with Materialized Views. I think it is great that the author explains some of the powerful features of PostgreSQL, but unfortunately the author dismisses the alternative of using a tool like Redis or Memcached or Elasticsearch without any discussion. It would be great if the author could share some of the reasons for selecting one approach over the other based on his experiences, so we could learn from his perspective. For example, I found the following reddit article that describes some of the tradeoffs between the two approaches: https://www.reddit.com/r/rails/comments/43vn9d/postgresql_materialized_views_and_alternatives/
“When I’d use Redis instead of Postgres’ materialized views: * If I wanted to relieve load on my database server. Easier to scale Redis out than to scale out a RDBMS. * If I wanted to cache something that isn’t relational data from Postgres, or something easily handled by Postgres’ FDW (foreign data wrappers) * If I was frequently writing to this data, didn’t need those writes to be ACID compliant, and I want those writes to be immediately available. * If I wanted the cached data to automatically expire after a while, since Redis makes this easy When I’d use Postgres’ materialized views instead of Redis: * When the data comes from inside Postgres or a FDW. * When the materialized view is updated due to stuff that happens inside Postgres, particularly if I want to share this logic across multiple applications. * When I’m not concerned too much about the view affecting the scalability of my database server… it’s not huge amounts of data, and I’m not reading/updating it hundreds of times per second.”
Perhaps these should be broken into seven separate topics.
I realize the above is opinionated. The author is perfectly within his rights to disagree with any/all of it. Happy to chat over email, if that is a better place than this forum: email@example.com Cheers