Note: This is an updated version of a previous blog.
by Candy Ng and Miroslav Bajtos
It has been an exciting time since IBM’s acquisition of StrongLoop while we’ve been realizing the promise of additional resources and partnership with our new co-workers. The LoopBack team has eight additional full-time developers contributing to the backlog, fixing bugs, enhancing the framework, and in general helping with LoopBack.
The triage process has many more hands and we’ve made a dent in the ever-growing number of open issues…finally! Not only is the number of issues going down, but people are receiving help a lot more quickly. We’ve streamlined maintainer responsibilities and created dedicated repository experts to handle community issues and examples. The goal is to answer your questions faster and fix issues faster.
Examples have finally been given their long-overdue care. We made the examples more full-featured as we have more resources to go in-depth. We have improved and finalized the example template; tutorials now follow a standard README format. We consolidated a few related examples to reduce the total number of repos.
Here is a short introduction to the Toronto LoopBack team and what they’ve achieved in the recent months.
Amirali Jafarian (@Amir-61 on GitHub) contributed to a couple of LoopBack modules to add new features for supported databases. He’s focused on LoopBack connectors, loopback-boot, and example projects, to name a few. He is an active member in the LoopBack community helping on documentation, and on triaging and resolving issues reported by the community. He likes to spend his free time with his family and friends, watching soccer, and travelling.
- loopback-datasource-juggler#898 – Implement forceId for
- loopback-datasource-juggler#788 – Implement replaceOrCreate, replaceAttributes and replaceById for all connectors and their operation hooks.
- loopback-datasource-juggler#893 – Add test coverages for hashed password for replaceAttributes and updateAttributes
- loopback-connector-mongodb#240 – Add eslint to loopback-connector-mongodb
- loopback-datasource-juggler#815 Implement fndOrCreate method for memory connector
- loopback-connector-mongodb#202 implement atomic version of replaceOrCreate and replaceById for Mongodb connector
- loopback-datasource-juggler#888 – Define patch aliases
Candy Ng (@0candy on GitHub) has been a key contributor to organizing the new team around getting started with LoopBack. She has mostly been working on swagger and component-explorer modules but lately has been working on other loopback module enhancements in LoopBack 3.0.
- loopback#2308 – Remove Change.handleError
- loopback-workspace#277 – Add eslint to loopback-workspace
- strong-remoting#294 – Set to no compression when using change stream
- loopback#2174 – Remove constraint making isStatic required
- strong-remoting#275 – Change method call to find remote method.
David Cheung (@davidcheung on GitHub) contributed fixes and enhancements to the Loopback Angular SDK and strong-remoting. David is focusing on Loopback front-end components and also has been updating documentation and example applications.
- loopback-boot#177 – dynamic configuration to resolve through environment variables
- strong-remoting#272 – allow customized rootElement for xml output
- strong-remoting#270 – retaining header content-type for empty content (http status:204)
Gunjan Pandya (@gunjpan on GitHub) is working on enhancing security of out-of-the-box LoopBack applications and some much-needed maintenance on the plethora of LoopBack examples. He has also become an active participant in the community, helping out with issues and bug fixes. In his free time, he likes to explore natural landscapes and capture them in pixels.
- loopback-workspace#236 – modified the project template to include helmet middleware as recommended by our recent blog post describing Best Practices for Express in Production
- loopback-workspace#239 – modified the project template to run “nsp check” as part of “npm test” in order to detect known security vulnerabilities in the dependencies used.
- loopback-workspace#235 – added support for starting the workspace app via “node .”. Before this change, one had to run “node server” instead.
Janny Hou (@jannyHou on GitHub), is working mostly on adding new features to connectors. She is involved in promisifying loopback apis and updating promise related changes. She is actively answering questions and solving issues. Specifically bug-fixing and compatibility-upgrading of generator-loopback. She enjoys reading in her spare time.
- loopback-connector-db2#31 – separated the connect phase from connector initialization, so connectors will skip the connect phase when loading app from swagger generator.
- loopback-connector-db2#23 – used connection string to override other settings and create connection when it’s provided.
- loopback#1999 – promisified model
Changein loopback core module.
- generator-loopback#187 – fixed relation generator by supporting promise return to be compatible with yeoman-generator
Loay Gewily (@loay on GitHub) has been heavily involved in the development of new enhancements related to databases and Passport, and addressing security related issues. He is also trying to help the community to fix the bugs that they may find when they use LoopBack. In his spare time, Loay enjoys watching and playing soccer.
- loopback-component-passport#136 – Add eslint infrastructure
- loopback-example-passport#73 – Fix loopback rest errors
- loopback-component-passport#121 – Fix email validation for LDAP
- loopback-component-passport#113 – Use Auto-generated email
Richard Pringle (@richardpringle on GitHub), has spread himself in breadth, combing through and fixing LoopBack’s issues and working with REST and remote connectors to improve remote capabilities. Additionally Richard has been applying his skills and working on GitHub tooling to improve team efficiency.
- strong-remoting#289 – Handle array of errors
- loopback-connector-remote#28 – added a unit-test to verify the connector honors custom http.path options.
- loopback#1804 – implemented an option to treat user emails as case-insensitive, for example to treat “firstname.lastname@example.org” as the same as “User@Example.com”.
Alex Pitigoi (@alexpit on GitHub) is the newest member of the team. He’s still learning LoopBack and getting up to speed and hasn’t had a chance to make any contributions yet. We expect to start seeing commits, PRs, and other contributions from him soon.
All said and done this helps our four LoopBack veterans (Raymond, Ritchie, Simon and Miroslav) to take a deeper look at the broader strategy and continue working toward high-value features on the LoopBack roadmap.
The future is coming
In upcoming sprints, we will address some of the most glaring open issues:
- Implement a more secure error handler for production environments. Our proposal is described in loopback#1650. Feel free to join the discussion and let us know if you have ideas on how to make the handler even better.
- We recently rewrote LoopBack Explorer to produce Swagger 2.0 documents. As more people use the new version, we’ve discovered few edge cases that are not handled correctly. Fixing these issues is among the priorities for the upcoming sprints.
- Improve LoopBack to work seamlessly with API Connect and on the cloud.
- Implement support for globalization and localization.
- Provide building blocks making it easy to implement multi-tenant applications.
Meanwhile, we are discussing how to make LoopBack even more awesome for you, the developers. It’s been some time since we made the last major release and we feel it’s time to give LoopBack a bit of refresh. Here is a sneak peek of areas we are thinking about:
- Fix up coercion issues in strong-remoting and loopback to ensure remote methods receive the expected values for input arguments, especially in various edge case scenarios.
- Improve the performance of LoopBack’s REST API server layer by implementing a custom router in strong-remoting that is tuned for routes created by LoopBack models. While this should be mostly backwards-compatible, there may be breaking changes in certain edge cases, therefore we prefer to release this in a new major version.
- In many places, preserving backwards compatibility required additional code, extra options, or even made the features more difficult to use. A new major version is the right time to pay off this debt.