Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Blade: a Java Web Framework

github.com

Post reply on HN
Print view View original

51–60 of 61 posts

Re: Blade: a Java Web Framework

#51

Post by true_religion »

cryptos wrote: post #18

I'm a bit tired of these sinatra like web frameworks these days. Repetitive url patterns are not that elegant. Why not simply building the API around the fundamental REST concept, the resource? And what about proper content negotiation? JAX-RS has a nice API without much boilerplate and it is more powerful than most "micro web frameworks".

I suppose it's because if your legacy products are already built with what's essentially a HTTP-RPC protocol, you're not going to want to build a REST-inspired framework.

I think REST is like the 3rd normal form of databases. In theory it's great, but in practice people only try to get close enough to the abstraction.

Re: Blade: a Java Web Framework

#52

Post by eip »

atomashpolskiy wrote: post #49
gd78 wrote: post #22

Could someone please explain me where the benefit is over using some embedded tomcat/jetty, weld, jersey, hibernate/jdbc? Setting up such a project cost me 30 min and gives me full flexibility choosing the stack I need for my project.

Speaking from my experience, benefit accumulates with the increasing number of applications under your authority, esp. in case each of these applications is some variation of CRUD Web Forms / Report Generation / Data Processing & Migration (read: typical enterprise environment) and shares most of its' dependencies with other applications, while still having a unique configuration. In such environment, having the mean…

>but the real game-changing feature is that you get a single "executable jar" artifact for deployment

Like a war file?

Re: Blade: a Java Web Framework

#53

Post by PeCaN »

mikkom wrote: post #23
onion2k wrote: post #20

Earlier quoted context omitted.

Speed is the problem. ocl-hashcat can test in the region of 6 billion MD5 hashes a second on a decent GPU. With a random salt and, say, an 8 character password it'd take a long time, but not so long it's impossible. On a site that includes rules like 'Must have an uppercase letter', 'Must include a number', and 'Must include a special character' you actually reduce the size of the space and consequently make the pass…

Okay I understand this much better now. I was assuming this was about remote access exploit not a local one. Point taken. Use SHA-? instead of MD5.

No! Use a proper key-derivation function (bcrypt, scrypt, pbkdf2), not a hash function.

SHA family, including the rather unrelated but exceptionally nifty SHA-3 (Keccak), are still hash functions and are still really fast to compute (good if you need to verify the contents of something, bad if you need to store secure information). A decent GPU can still crack SHA hashes effortlessly, and a dedicated attacker will have some good FPGAs (in which case you'll be cracked in hours). Use a function that is meant for storing passwords.

Re: Blade: a Java Web Framework

#55

Post by mikkom »

PeCaN wrote: post #53
mikkom wrote: post #23

Earlier quoted context omitted.

Okay I understand this much better now. I was assuming this was about remote access exploit not a local one. Point taken. Use SHA-? instead of MD5.

No! Use a proper key-derivation function (bcrypt, scrypt, pbkdf2), not a hash function. SHA family, including the rather unrelated but exceptionally nifty SHA-3 (Keccak), are still hash functions and are still really fast to compute (good if you need to verify the contents of something, bad if you need to store secure information). A decent GPU can still crack SHA hashes effortlessly, and a dedicated attacker will ha…

:-) Bcrypt it is then.

Re: Blade: a Java Web Framework

#56

Post by paulddraper »

cname wrote: post #54

> REST style routing interface I'm fairly certain there is no such thing, and parsing parameters out of the URL path has nothing to do with REST either.

Sort of. URL "routing" is necessary for REST, as opposed to an RPC (or GraphQL) style POST to a single URL.

But yes, other than arbitrary URL routing existing, there is nothing that makes it have a "REST" style.

Re: Blade: a Java Web Framework

#57

Post by sbanach »

dangoldin wrote: post #42
sscarduzio wrote: post #14

No offence, but this is basically the poor man's Finagle. Except Finagle is Netty based, and this is Jetty based. Anyway, this API is really as terse as one can get with Java. Great developer-UX job!

That's the first thing I looked at - whether these were Netty based. We've been using raw Netty for our core application and it's been amazing.

Quick question: What's the draw of using Netty vs pure java.nio? The latter (Selectors, Socket/DatagramChannels, ByteBuffers etc) seems reasonably straightforward to use, so I've never really looked at a framework - am I missing out?

Re: Blade: a Java Web Framework

#58

Post by bullen »

sbanach wrote: post #57
dangoldin wrote: post #42

Earlier quoted context omitted.

That's the first thing I looked at - whether these were Netty based. We've been using raw Netty for our core application and it's been amazing.

Quick question: What's the draw of using Netty vs pure java.nio? The latter (Selectors, Socket/DatagramChannels, ByteBuffers etc) seems reasonably straightforward to use, so I've never really looked at a framework - am I missing out?

It's hard to synchronize: http://github.com/tinspin/rupy

Re: Blade: a Java Web Framework

#59

Post by cname »

paulddraper wrote: post #56
cname wrote: post #54

> REST style routing interface I'm fairly certain there is no such thing, and parsing parameters out of the URL path has nothing to do with REST either.

Sort of. URL "routing" is necessary for REST, as opposed to an RPC (or GraphQL) style POST to a single URL. But yes, other than arbitrary URL routing existing, there is nothing that makes it have a "REST" style.

REST only requires uniquely-identified resources. There's nothing in that stopping you from having a single endpoint that takes query parameters to identify those resources.

Re: Blade: a Java Web Framework

#60

Post by paulddraper »

cname wrote: post #59
paulddraper wrote: post #56

Earlier quoted context omitted.

Sort of. URL "routing" is necessary for REST, as opposed to an RPC (or GraphQL) style POST to a single URL. But yes, other than arbitrary URL routing existing, there is nothing that makes it have a "REST" style.

REST only requires uniquely-identified resources. There's nothing in that stopping you from having a single endpoint that takes query parameters to identify those resources.

Yes, but that doesn't invalidate what I said. It still counts as "routing" on the request URI.

(Instead of, say, routing to application logic primarily based on a header or the entity like GraphQL).

There's zero difference between path and query string, other than one is meant to be hierarchial and the other is not.

Post reply on HN