168 karma · joined February 9, 2015
Software Engineer and Developer with a lot of experience in the area of full stack web development. I have been designing and building scalable backend servers and web frontends for more than 6 years.
Technologies:
- Node.js
- Go
- JavaScript incl. React
- Python
- Java
- Linux
- AWS
Website: https://accoplex.com/
Email: marius[at]accoplex.com
First of all, thank you for publishing this project. It's very interesting in my opinion since I never thought about the benefits of an event loop. Would you mind explaining briefly why an event loop is a better suit for these applications? Is it due to performance and efficiency?
I very much agree. In the past, I have had quite some fun developing a few streaming parsers using Node.js, which also uses an event loop. And while these parser worked relatively good and efficient, debugging them was not an easy task. In addition, understanding the code is also a though challenge, especially for people other than the original authors.
When I started using Go more and more, I really enjoyed the different I/O-model using goroutines and blocking function calls. It also has a few drawbacks but the mental model is a lot easier to reason about.
Does anyone have experience with distributed locks and would be kind enough to share?
We also considered the use of the Content-Range headers for resuming uploads but dropped this idea in favour of custom headers since the purpose written down in the HTTP specification was not compatible with the way we wanted to use it.
The biggest benefit and the main reason of its origin is the ability to resume an interrupted upload at any time resulting in more efficient resource usage and user experience. In addition the fact that it's developed openly and by a community is also noticeable. You do not have to reinvent the wheel since others have already spend time, efforts and thoughts building a working system you can use for free. The tus project already offers a growing list of client and server-side implementations. Last but not least, optional features such as parallel uploading and checksums are available.
On the other hand, you have the overhead of adapting an external system. Whenever you want to build software, you can choose between doing it yourself or using an existing solution, where latter can be tough to achieve depending on your architecture. Furthermore, tus introduces a small overhead in terms of numbers of requests needed for an upload. Usually, you need one to create the upload and another one to transfer the actual data (excluding eventual CORS requests in a browser), in contrast to the traditional model of uploading where a single request is used. Normally, this overhead is negligible, especially when the files are getting bigger.
In my freetime I try to publish as much code as possible although it doesn't get much attention but without this I would not have gotten the job. For me open-source is not about getting famous or working on the next big thing but giving the community something back and not just consuming the work of others.