Review of the Raijintek Morpheus II Core Edition: Big, cool, complicated

Did you ever want a quieter graphics card? Or did you have one that was running perfectly fine until a fan broke, making it overheat all the time? If you searched for a solution, you stumbled maybe already over the Raijintek Morpheus II Core Edition, its predecessors or one of the few alternatives.

The Morpheus II is an aftermarket gpu cooler. Its promise is that by replacing the regular gpu cooler with this very big heatsink and strapping two 120mm case fans on top of it you end up with a less hot and quieter graphics card. The fans you have to buy yourself, the idea is to use regular case fans. The cooler supports a TDP of 360W, which is a lot.

It is not cheap though. I bought it myself at caseking for 64.90€, in the US the best offer I see right now is for $67.99 at newegg.

The question is: Is it worth it?

To decide that I will show how I installed the cooler plus fans on a Sapphire Pulse RX 580, a card that was before that installation very loud and ran too hot. I measured temperature before and after, and made recordings of the noise difference.

A closer look

The Morpheus II Core Edition does not seem to differ much from the regular Morpheus II. It is black, that’s all, apart from that the content of the box seems to be the same.

There is for one the heatsink itself:

/blog/upload/02_morhpeus_II.jpg

It is not small, but less heavy than I expected. For the gpu that is good news, a too heavy cooler can lead to gpu sag.

Additionally included is a manual, a bunch of small heatsinks with double sided tape, thermal paste, some screws, a metal holder for the screws at the back of the gpu, a slightly bigger VRM cooler plus fitting heatpads, metal brackets that act as connectors between gpu and heatsink as well as fitting coupling nuts, and metal brackets for the fan installation.

/blog/upload/1_box_content_curved.jpg

There is also black tape that the manual calls fan tape, I figured it goes between the fans and the heatsink and is meant to minimize the travel of vibrations, reducing noise.

What is missing from the box are the fans. The Morpheus II comes without fans, but it should definitely be combined with two of them to properly move the heat away from the heatsink and also to cool the VRM. I opted for two Arctic F12 PWM Rev 2 case fans. Those fans are not the strongest on the market, but one of the cheaper options. In my opinion they cool sufficiently well and stay quiet enough. Though I was not sure whether they would work well behind a heatsink like this.

I also had to buy a PWM Y-splitter, and a VGA PWM adapter cable to connect that splitter to the 4-pin fanslot of the gpu. That way the gpu can directly control the speed of the fans based on its temperature.

Installation

I should preface this section with a warning: The installation of this cooler takes time and is not easy. It is made harder than it needs to be by the manual, which is just very bad and incomplete. Removing the stock cooler will void the warranty, at least for most brands (exceptions are EVGA, XFX in the US, and also MSI claims to not void warranty when exchanging the cooler). Knowing that there most likely is no warranty in case something goes wrong will make the installation more stressful.

/blog/upload/03_pulse_back.jpg

I started by removing the screws at the back of the gpu. That way the plastic shroud holding the fans can be removed, also the stock heatsink that normally sits below. The backplate can at this point be removed easily as well.

/blog/upload/04_vga_pwm_slot.jpg

It was very hard to disconnect the fan cable, I had to use force to succeed here and was very worried that I just broke the fan header. But nothing bad did happen to it.

/blog/upload/05_pulse_bare.jpg

Doesn’t the bare card look unusual, without all the usual stuff around it?

/blog/upload/06_brackets_heatsink.jpg

The brackets that get screwed to the heatsink should be installed now. You see that there are several holes at the end, this is where the heatsink will be connected to the gpu later. Depending on the gpu a different combination of holes needs to be used then, for now just install the coupling nuts there.

/blog/upload/07_vrm_heatsinks.jpg

Now the small heatsinks (sometimes also called heatspreaders) can be installed on top of the gpu. The manual is not very clear about where they have to be installed. It is a good idea to look at the original cooler for that: The Sapphire Pulse RX 580 for example has thermal pads on the heatsink where it will touch the Vram modules around the core of the card. Its heatsink also covers the VRM, again with thermalpads making the connection.

/blog/upload/08_original_thermalpads.jpg

The small heatsinks can be glued with the included double sided (thermal) tape on top the Vram modules. Careful: Some of them need to be covered by the smaller heatsink or the Morpheus cooler will later not fit on the core.

/blog/upload/15_thermalpad_heatsink_improv.jpg

One Vram block I even had to cover with some thermalpad and move the heatsink to the far side of the gpu core, otherwise the Morpheus heatsink would not have fit.

The mosfets of the VRM should be covered by the small VRM heatsink that comes with the box.

/blog/upload/09_overlong_vrm_heatsink.jpg

In the case of my RX 580 this does not work: The heatsink is just too long.

/blog/upload/10_improvised_vrm_heatsink.jpg

After realizing that no one sells a fitting VRM heatsink I used some of the smaller heatsinks instead and hoped for the best - the tape does not hold very strongly here, and it would have been better to use the provided VRM heatsink, as that one ought to connect to the Morpheus cooler later, transporting the heat more efficiently away.

At this point don’t forget to install the VGA to PWM adapter cable.

If Vram and VRM are properly covered the Morpheus II can be installed. First step is to apply thermal paste on the core. I used a different one than included because it was already open, the difference should not matter. Then I put the heatsink on the table and moved the gpu to the right position, so that the screws holding them together would fit into the bracket with the coupling nuts installed above.

But what about the backplate? The Morpheus comes with that metal X that can hold the heatsink to the gpu, like a mini-backplate. The manual makes no mention of what to do with the real backplate, according to the diagrams it just gets left off (or rather: never existed).

/blog/upload/11_installed_x.jpg

For the RX 580 Pulse I instead opted to use the metal X and the backplate together, with the backplate touching the gpu and the X coming on top of that. The screws that before hold the stock heatsink are longer than the screws that come with the Morpheus II, they were long enough to connect both the metal X and the backplate to the heatsink.

/blog/upload/12_fantape.jpg

To prepare the fans for installation I glued the fan tape to the plastic bracket, where that would touch the heatsink later. I also put some between the two fans, to make sure they can’t produce noise by vibrating against each other.

/blog/upload/13_fan_brackets.jpg

Afterwards I put the fans on top of the heatsink… and then needed a moment to figure out how the metal brackets work. Again the manual is pretty hard to decipher, the images too small. The metal brackets work like a lever or a rocker, by pressing on the extruded part the parts closer to the heatsink can be pressed into a small gap in the middle of the heatsink. After understanding how that works it’s actually not hard, and the fans seemed to be properly installed afterwards. It’s a smart solution, similar to how Noctua coolers hold their fans, but a bit easier to install.

/blog/upload/14_morpheus_installed.jpg

You end up with a strange looking gpu that looks like it has an oversized heatsink. Which is accurate, it really is big: While regular gpus use 2 or 2.5 PCI-E slots, a gpu with the Morpheus II and regular case fans installed will need 4. It is also longer than the card was before, only barely fitting into the case.

Noise and Temperature

The big cooler also had a big effect on noise and temperature. Listen yourself:

Recording before:

Recording with Morpheus:

That’s while playing Witcher 3 with the same fan curve.

I should have used a better microphone, but the difference is very clear: The regular cooler was louder than reasonable, louder than normal. The Morpheus II is the contrary, it is very very quiet. The noise it emits depends of course partly on the fans used, as they produce the noise. But it is to a big part the heatsink that defines how many RPM are needed and thus how loud the fans are. The fans can turn slowly if the heatsink is efficient and cools well.

/blog/upload/temps_morpheus_load_tiny.png

Exactly that happens with the Morpheus. While before in Witcher 3 the card reached 77°C in the test case despite the fans running almost at max speed (like said, not completely normal behaviour) it now reached 57°C. That’s very good, good enough to change the fan curve and make the fans spin even slower and quieter.

Conclusion

The Raijintek Morpheus II Core Edition holds its promise: It is a very good cooler that can make a huge difference in terms of temperature and noise. It is way better than the stock cooler normally used with graphics cards. For an expensive card that would otherwise be too loud or too hot it is an excellent option.

There are drawbacks though. It is heavy (compared to the default coolers) and needs a lot of space. It is also expensive: ~70 USD or Euro plus the money needed for the two case fans and the cables to connect them, that easily adds up to 100 bucks. That’s a lot, and it makes the Morpheus unattractive when thinking about installing it on a new card. It will almost always be cheaper to get a better card instead that already comes with an acceptable cooler. Even if that cooler will not be as good as the Morpheus II.

But the biggest drawback is the manual.

/blog/upload/manual.jpg

I understand that this is not a product for beginners, someone new to building PCs hopefully won’t start his first build by ripping his gpu cooler off and trying to install a cooler like the Morpheus II. But even more experienced builder would profit from getting a better manual, with bigger diagrams that better explain how to install all the parts, and that also explains in detail which components of the gpu (like mosfets etc) should be cooled with a separate heatsink.

Compatibility is also problematic. Though it must be said that Raijintek never claimed it would work with a RX 480 or 580, also the RX 470 and RX 570 are not listed in the compatibility list. For Vega there is a specialized version. Issues like the VRM heatsink not fitting are less likely to occur when getting a card from a series that is officially supported. But if all needed to support those AMD cards is to add a smaller VRM heatsink and one very low Vram heatsink one has to wonder why those parts are not included already - at least optional, at an additional cost.

The Raijintek Morpheus II Core Edition can be worth it: Either if reducing noise is of the highest priority, or if a broken cooler has to be replaced. But as it is very big, quite expensive and not easy to install it is not for everybody.

AMD's cheaper Threadripper 2: 2970WX & 2920X vs Intel i9-7980XE and the best consumer processors

AMD’s second release of Threadripper 2 processors always looked promising. The earlier Threadripper 2990WX and 2950X worked well as high core count processors, but were on the more extreme end of price and performance. Especially the expensive 2990WX was problematic, as it could only shine in some very specific situations. Now the cheaper alternatives got released and might be more convincing by just being less extreme:

  1. The Threadripper 2970WX, with 24 cores and 48 threads, currently at $1299.
  2. The Threadripper 2920X, with 12 cores and 24 threads, currently at $649.

The boost clock is at 4.3GHz for the 2920X, and at 4.2GHz for the 2970WX. They are as such slightly smaller versions of the 2990WX (32 cores, 64 thread) and the 2950X (16 cores, 32 threads).

This release was all about balance. Would the two new processors find the right balance between price and core count, and be suited for a broad range of application as well as games? That is something especially the 2990WX failed to deliver, having too many cores for games and other applications that focus on single thread performance.

For gaming the new Threadripper processors show a surprising performance:

/blog/upload/meta_gaming_2970WX_tiny.png

To see exactly which benchmarks were used, check the comparison page.

The surprising result here is the placement below the more expensive processors. I fully expected the new versions to be faster in games, as having less cores is advantageous in most games. This shows how well the gaming modes work, and how well the higher turbo clock of the 2950X gets applied.

As it is, the strongest Threadripper 2 for games is the 2950X, presumably because of its high turbo clock. But it still is not faster than the Ryen 7 2700X. The 2990WX follows. The new 2920X is faster than the new 2970WX, as to be expected from their turbo clock. We can see that a regular quad core like the Ryzen 5 2400G is not much slower - and that processor costs around 10% of the 2970WX. The small differences between between the Threadripper models make the most reasonable Threadripper 2 for gaming the cheapest, which is the 2920X.

In other words: Gaming is just not Threadripper’s strong suit, the way cheaper Ryzen 7 2700X remains AMD’s fastest gaming processor.

The result also shows the strong position of Intel. Intel’s processors are just faster in games, even Intel’s high core count i9-7980XE is placed above the Threadripper family. But the i9-9900K and the i7-9700K are even better in games, with the i9-9900K being the strongest gaming processor in the whole benchmark.

Software workloads are a different story:

/blog/upload/meta_software_2970WX.png

To see exactly which benchmarks were used, check again the comparison page.

As said in the review of Intel’s 9000 series: Software performance differs a lot, and there are areas where single thread performance matters more. In software relying on memory latency or single core speed the results will be closer to the gaming benchmark above. That said, let’s look at the results in this benchmark.

The 2990WX sits at the top, the 2970X can get the second position. And while the i9-7980XE is faster than the remaining Threadrippers it is also a lot more expensive, giving AMD a clear lead in software performance. Even the very high clock of the i9-9900X is not enough to beat the slowest new Threadripper, the 2920X.

The 2950X reaches a strong placement as well, it is a good option when running software that does not scale that well with many cores. The same could be said about the 2920X, but that processor has the additional advantage of being cheaper - the small difference between that model and the i9-9900K make it an attractive option for those that focus less on gaming performance, but who want more multi-thread performance than a regular consumer processor can offer. Of those the Ryzen 7 2700X has the usual strong price-performance.


It was to be expected that Threadripper 2 would not solve all issues of the Treadripper series. And indeed, the core problem (pun intended) remains: Those are expensive processors that only impress in some multi-threaded workloads. But AMD managed to up the core count without reducing gaming performance, that way staying close to the gaming performance of a good Ryzen processor. Which also means gaming performance is worse than with Intel. And that it is absolutely good enough.

But no one buys a Threadripper for gaming. And right: In application workloads Threadripper 2 beats Intel’s offerings, even the expensive high core count option that is the i9-7980XE. That this also holds true for the clearly cheaper 2970WX is a very good result for AMD.

onli,

Intel's new 9000 series: i9-9900K, i7-9700K and i5-9600K vs i7-8700K and Ryzen 7 2700X

Intel’s new processors were announced as the fastest gaming processors, and to be also quite fast in other application workloads. Coffee Lake Refresh includes three processors:

  1. The i9-9900K, with 8 cores and 16 threads, currently at $579.99
  2. The i7-9700K, with 8 cores and 8 threads, currently at $409.99
  3. The i5-9600K, with 6 cores and 6 threads, currently at $279.99

All of them reach a high turbo clock: the i9 5.0, the i7 4.9 and the i5 4.6 GHz - without overclocking.

That is a very special release. It’s the first time that Intel releases consumer processors with 8 cores. It’s also the first time Intel releases an i7 without hyperthreading, presumable to give the new i9-9900K a reason to exist. And it’s the first reaction to AMD’s Ryzen processors where Intel had some time to prepare.

Now, we already know the i9-9900k gets hot. But how is the performance? Also the i7-9700K is very interesting this time: Its predecessor, the i7-8700K, had only 6 cores but with 12 threads 4 threads more. Will the missing hyperthreading limit the performance more than the two additional cores and the higher turbo clock can make up for?

Over the last days I gathered reviews for the pc-kombo meta benchmark. The meta benchmark creates a global order out of many distinct smaller benchmarks, currently more than 282. Based on that benchmarks one can not judge how many FPS a processors will reach exactly, but one can judge which processor is faster overall.

Let’s look at gaming performance first:

/blog/upload/meta_gaming_9000_tiny.png

To see exactly which benchmarks were used, check the comparison page.

The i9-9900K is the fastest gaming processor overall. As the core and thread counts suggest it beats the 9700K. And the i7-9700K beats the former champion, the i7-8700K: Turns out that hyperthreading is less useful than having more cores available. The higher turbo block also won’t hurt this result.

For everyone wanting to use less money it will be nice to know that the i5-9600K stays quite close to the i7-8700K. Since the i7-8700K is not that much slower than the i7-9700K that means that the i5-9600K is still a good option for high FPS gaming, with a similar performance as the i5-8600K. As a result the Ryzen 7 2700X can’t compete here.

However, let’s not forget that the gaming performance of the Ryzen 7 2700X and the Ryzen 5 2600X is still high enough to play all current games properly. It’s just in the high FPS area where Intel was already stronger before this release, and now has a slightly higher lead.

Outside of gaming Intel also reach a very high position with its new processors:

/blog/upload/meta_software_9000_tiny.png

Again, to see exactly which benchmarks were used, check the comparison page.

Finally reaching 8 cores lets Intel overtake the Ryzen 7 2700X in the software performance benchmark, a big win. But the difference is not as big as in gaming, and the smaller chips do not win against the Ryzen processor. Having 16 threads available helps it to keep its position against the i7-9700K. And the i5-9600K does not fare well in this benchmarks, though the 9600K did not see many reviews yet and will likely improve later on when more data is added. It should also be noted that software performance is a huge field, and in some applications the performance rating will be more similar to the above gaming performance.

Still, it’s a good result for Intel. The i9-9900K gets a good rating here, and also the i7-9700K does very well. The real star of this benchmark are processors with an extremely high core count, like the workstation i9 and Threadripper. But this is the best result Intel could have hoped to reach on their consumer platform: Beating the AMD Ryzen 7 2700X on raw performance.


Time for a conclusion. The 9000 series has some issues. Those are hot processors hat eat a lot of energy, and they are also very expensive, especially the i9-9900K. But with that i9-9900K Intel for the first time since Ryzen placed a processor on the consumer market that can beat AMD on gaming and multi-threaded application performance, while before Intel only had a lead in gaming. But the i9 is sadly also very expensive, making the Ryzen 7 2700X for many budgets a more attractive option.

The i7-9700K and the i5-9600K are less special. They replace the i7-8700K and the i5-8600K and deliver a small performance improvement, but they do not change the overall situations: Less performance in multi-threaded software workloads than Ryzen, but a better performance in gaming.

As a result, the i9-9900K is the best option currently for those wanting the absolute best performance without making the step to a way more expensive workstation processor, but only for those willing to also buy the best possible cooling hardware and willing to disregard price-performance. The i7-9700K and the i5-9600K can be interchanged with the i7-8700K and the i5-8600K depending on their price, they are best suited for gaming builds targeting 144 FPS. For regular 60Hz gaming (regardless on which resolution) the Ryzen 5 2600X and the Intel Core i5-8400 are still the smarter option, with the Ryzen 5 2600 being a cheaper alternative.

onli,

New Intel Core i9 gets very very hot

Intel releasing consumer processors with 8 cores is a big deal, and I know that many gamers were very excited about this release. If the hexa-cores are already stronger than Ryzen, how much better will the new processors be? It turns out not that much, at least in games. But it will take some time till the meta benchmark gets an update, so we will cover this later. For now, let’s look at their temps.

Because it turns out the i7-9700K and especially the i9-9900K get very hot. Hardware Unboxed released a review video showing this graph:

/blog/upload/9900K_temps_tiny.png

Note that the air cooler reaches 84°C without an overclock, which is very high. And this is not your run of the mill air cooler, the Noctua NH-D15 is right at the top of air cooling performance. As a result, overclocking these processors will basically be impossible, and even without overclocking you need the best cooling money can buy to run them properly.

This is a problem. In the following days we will adapt the hardware recommender to prevent users from accidentally combining these processors with cooler that are too weak for them.

onli,

Where Ruby/Sinatra falls short

The PC hardware recommender pc-kombo is written with Ruby and Sinatra, a very comfortable and powerful small framework to build web applications. Web applications is where Ruby shines in general, the language got popular together with the more complete (and opinionated) Ruby on Rails framework.

Sinatra is very nice to work with initially, but over the years it became clear to me that not everything works as good as it should. I’d still recommend it, but would urge beginners to be aware of its limitations.

Some of Sinatra’s issues

/blog/upload/Sinatra_tiny.png

1. The routing order matters, and evaluation is not always obvious

That’s stated in the documentation:

Routes are matched in the order they are defined. The first route that matches the request is invoked.

Sounds straightforward, but in practice this gets complicated. As soon as you have routes that match by regexpressions, you won’t always know which order is the correct one. This lead to several situations where we had to shuffle the routes around in our server.rb, where the routes are defined.

Worse: The evaluations order changes over time. Whether it was from Sinatra or Ruby version mismatches, several times everything worked as expected on the dev platform, while as soon as the new routes were added to the production server they covered other, more important routes. Something changed the evaluation order, which lead to frantically searching the right position to define the route. Now imagine not having a classical style Sinatra app, but a modular one.

And a small issue on top of that: If you define /route, /route/ will still throw a 404. The right solution would be to serve the page on the two routes but set one as canonical source. But you have to do that manually.

2. How do you start this thing?

Have a look at the readme. It gives a definite answer on how to start Sinatra:

ruby myapp.rb

Now, isn’t it surprising that this is not how I start my Sinatra application? I have to run

bundle exec puma -e development

The bundle exec is not the fault of Sinatra, that’s just a wrapper to solve dependency management. But the puma -e development should be surprising, as should be that I had to define a config.ru. That files gets mentioned in the Readme, but what it is for does not get explained.

Sinatra is part of a broader Ruby web ecosystem around the Rack web environment and with influences from Rails. Ever so often parts from there will become relevant to you when you use Sinatra, but if you don’t already know all about Rack and Rails, then you’ll be lost until figuring this ecosystem out.

3. The application webserver story is strong but confusing

So apart from the problem with starting it, what exactly did it start? Sinatra by default can run with multiple application servers. By default is searches for thin, mongrel or webrick, in this order. But maybe you want to run a different server? The start command above shows I use puma. But there is also unicorn, passenger, falcon, and probably many more. It is nice to have many good options, but which one is right for you? Which one can scale the incoming requests properly, ideally over multiple cores?

And besides: If Sinatra starts a server listening for incoming traffic, why does it still seem common to run a regular webserver like nginx in front of that server? Wouldn’t it be better to map port 80 to the application server port with a firewall rule and serve the application directly? Will the url rewriting used in the template understand your setup?

All those questions are not properly answered by the documentation, and you are on your own to find a setup that works for you.

4. There are too many ways to access parameters

The documentation shows this well. There are many ways to react to information given as part of the url or as POST/GET parameter. Let’s count, citing from the Readme again. First there are named parameters, accessible via the params hash:

get '/hello/:name' do
    # matches "GET /hello/foo" and "GET /hello/bar"
    # params['name'] is 'foo' or 'bar'
    "Hello #{params['name']}!"
end

Or you can put them into a block:

get '/hello/:name' do |n|
    # matches "GET /hello/foo" and "GET /hello/bar"
    # params['name'] is 'foo' or 'bar'
    # n stores params['name']
    "Hello #{n}!"
end

You can also use wildcards with params['splat']:

get '/say/*/to/*' do
    # matches /say/hello/to/world
    params['splat'] # => ["hello", "world"]
end

get '/download/*.*' do
    # matches /download/path/to/file.xml
    params['splat'] # => ["path/to/file", "xml"]
end

Or they can be blocks:

get '/download/*.*' do |path, ext|
    [path, ext] # => ["path/to/file", "xml"]
end

Or use a regexpression with params['captures']:

get /\/hello\/([\w]+)/ do
    "Hello, #{params['captures'].first}!"
end

And those can also be blocks:

get %r{/hello/([\w]+)} do |c|
    # Matches "GET /meta/hello/world", "GET /hello/world/1234" etc.
    "Hello, #{c}!"
end

And that’s not all, there are still optional parameters, and params also contains the regular GET and POST parameters like ?param1=abc&param2=def (by the way: what happens when you send an URL like that as a POST method?). So let’s stop counting here, there is no clear number.

I get that Sinatra wants to be unopinionated and provide several good solutions, but a range of options this broad just leads to chaos.

5. You will need much more than included

Some common scenarios I guarantee you will run into:

  1. HTML-escaping a string in your template
  2. Serving a translated page for visitors from other countries
  3. Rewriting www.yourpage.com to yourpage.com, or the other way around
  4. Serving your site over https
  5. Redirecting all http:// pages to https://
  6. Running tasks in the background
  7. Saving data in a database, and reading from it

All of that you will have to solve outside of Sinatra, with gems like rack-rewrite (using the config.ru from above), picking from Rack::Utils or using sanitize, concepts like threadpools or queues, maybe using additional programs like Redis.

Not all of that is bad: Having to solve database access on your own leads naturally to writing raw SQL, which is often the best solution anyway. But easy problems like escaping HTML get surprisingly hard when your framework does not provide it and you have to figure out how to transport the Rails-centric solutions you find online to your Sinatra program.

6. Which helpers are available anyway?

Sinatra has a lot of useful stuff included, but you have to discover it. And the only place for that seems to be the Readme. This can be slightly problematic. For example: Writing urls in the template often profits from not hardcoding your url, and a gem like url_for can do that. I was still using an external solution way past the moment Sinatra included its own url method, because I was simply not aware of that.

There are solutions for mime types, cache control, redirects, logging, sending files, dealing with dates and some more. And in sinatra-contrib there is some more specialized stuff that will be less often needed. But all that means that you have to think at the right moment to check the Readme, because since not everything is included, sometimes you will miss that a solution to your specific problem is already there.

7. The issue with sessions

Sessions are great, but we ran into overusing them. And there are several per-requisites to make them work. It starts with security:

For better security and usability it’s recommended that you generate a secure random secret and store it in an environment variable on each host running your application so that all of your application instances will share the same secret. You should periodically rotate this session secret to a new value. Here are some examples of how you might create a 64 byte secret and set it

and goes on to realizing you have to use Rack::Session::Pool to be able to store more than the simple values (by storing them on the servers instead of in the visitors cookie). And finally it is being quite complicated to not have multiple session middlewares running by just following the code in the Readme.

There are also not that many alternatives, not many session middlewares you can actually use. There basically is moneta, and while a great project I did not see many reports of the advantages - apart from storing session in a SQL database and thus making them persistent over application restarts while keeping the flexibility of Rack::Session::Pool of what can be stored.

But our main problem was and is overusing sessions. In transporting data via sessions it is too easy to create an application where sharing an url will not lead to the second person seeing the same content on the shared url. That’s why we need a share button to create a permalink after creating a PC build. Now, that’s not really the fault of Sinatra – it’s an architectural issue. But shouldn’t it be the job of the web framework to provide a better alternative? A way to map application content to urls where a part of the url changes with the content? Maybe that is just too specific to pc-kombo, but something to keep in mind when building a similar dynamic application.

8. The built-in protection will block valid access patterns

This was a bad one. Sinatra uses Rack::Protection to prevent a whole bunch of typical attacks. But that way it also blocks valid access patterns, like transporting the jwt access token from the portier authentication system. And then basically the worst case happened in a different project: An early launch that got a lot more publicity than expected with a bunch of visitors not being able to login, because the protection blocked the access token from all visitors using Chrome. Just the most popular browser out there. I had to disable parts of that to make it work, which kind of defeats the purpose of having the protection built in.

9. And finally: Is Ruby the right language for you?

If you start with Sinatra, maybe you do want to start with a cheap server. Who knows whether the new application will earn any money, or maybe earning money is not even the goal. A good way could be a low-power multi-core server like the ones provided by Scaleway, 4 ARM cores for cheap are a good fit for many web applications. Or maybe you know you will get many visitors and want something as efficient as possible.

In that case, at first glance Sinatra is not a bad fit. Compared to Rails it is very lightweight, which has a positive effect on performance.

But the problem might be Ruby. If you use the regular C-Ruby, you use a language that has a very prominent Global Interpreter Lock, and that GIL basically means that your app will be very bad in using multiple small cores. Depending on where you want to deploy your webapp and how many visitors it will serve that might be a problem.

It is still a nice solution

I don’t want to end that article without saying something positive. My true point is: Do not evade Sinatra, but be aware of its shortcomings before starting a project with it.

While the above focuses on Sinatra’s shortcomings, that does not mean that I think it is a bad solution. To the contrary: There are not many web frameworks out there that enable such a nice and fast initial developer experience. With its DSL approach and by providing quite a bunch of solutions to common problems Sinatra is still a great tool for making web apps that work and that can get developed fast. It is even better for just providing an API, or for a very focused web app. It just gets less nice when you realize that the moment you chose Sinatra you also put yourself in a situation where you later will definitely be in uncharted territory.

After you solved those issues once you will have your toolset that covers at least most of those typical issues as well. And you will be more capable for it, regardless with which language and framework you develop your next web application. But till then there will be a lot of uncertainty whether you can succeed with your current Sinatra project at all. And all the time you will find search results showing how to do it in Rails, or with a different more complete framework in a different language.

That’s exciting for some, but not right for every project and not something every developer will want.

onli,