API?

[ServiceSector]

I'm looking for something like this but with weight integration, this library seems to be it, however there doesn't seem to be an API integration like the other package. How would one implement this?

[shakethatweight-simon]

There's no API, but if you're already working in PHP it should be easy enough to integrate this package. If you don't have access to PHP then I can understand why you might want an API.

[ServiceSector]

Haha I've tried almost 40 different box packers, when one couldn't handle weights (algorithmic limitation) it would resolve the boxes needed perfectly, when one could handle weights it didn't work at all, or some variation of that. Some came so close, namely SardineCan, it even had the API integrated, but IIRC it couldn't resolve the output when I spun it up. There was even one from a user that titled himself "the best programmer in Korea" that was tantalizing promising, but it didn't handle weights, not his fault, it was the algorithm itself that the wrapper used that couldn't handle weights.

This project here looks tailormade for the problem I have: packing x items into boxes of given types with max weights, but I've been avoiding it due to not wanting to dive back into PHP. Now it looks like there is no other alternative other than trying my hand at rewriting what was made here for JS/TS applications, a paid alternative (but it's so irritating that such a simple problem is so hard, that I don't want to), or trying to use this PHP plugin somehow. I've been hitting the problem from all sides for I think 3 days now and it's one of the hardest problems I've ever faced in programming, though I thought that there would for sure be an easy fix somewhere on NPM, because the problem seems so obvious and common.

On a sidenote, I just think that in the 21st century with climate change and pollution being such large issues, an open-source library like this and others are essential to attempt to optimize and reduce the packaging necessary by all kinds of companies and other agents. For example, imagine a plugin for Woocommerce (and I'm sure Automattic is already working on it) that integrates this plugin by default into the 1 million Woocommerce stores in the world.

Now my proposed solution is to spin up a PHP REST boilerplate on docker, install this plugin into it, somehow make it so that when I call it from my JS/TS application with a JSON input of items (dimensions + weights) and containers (max dimensions and max weights), this plugin will calculate that and vomit out the necessary boxes needed.

If it works, I'll make a guide for other JS/TS users.

[ServiceSector]

It's working flawlessly as an API within a SLIM framework instance. I'll make a guide when I'm done, and send it to the author, maybe they can pin it somewhere

Stunning work here, I should've just bit the bullet earlier 😂

[ServiceSector]

It's done. It's deployed on a SLIM framework instance on gCloud, the API is responding. My brain can't even process that I finished it already. It was flawless

The only hiccup was that it couldn't really handle decimals, so anything like 0.5 it would break the calculation. I've seen other libraries handle that internally by multiplying the input number by 10000 for example and dividing internally the output by 10000. I would have done that but I think the original devs would be able to handle that more elegantly than I could. I read somewhere on here something about integers, and 0.35 meters is not an int, but that's easy to work around on the client side.

[shakethatweight-simon]

There are regular issues raised for float values, but there is a real reason for not supporting it in PHP. See this comment from the author of this software: https://github.com/dvdoug/BoxPacker/issues/215#issuecomment-723476105 - if you know your own accuracy, then use your API wrapper to multiple up all the values on the input and divide back down before sending back the responses. We use grams for weight, and mm for measurements which is enough accuracy for us.

[dvdoug]

Yeah, no "official" API. Mostly because of the nature of the library, with the design choice to allow applications to use their own objects - taking advantage of that functionality obviously requires app-specific knowledge.

it's one of the hardest problems I've ever faced in programming, though I thought that there would for sure be an easy fix somewhere [....], because the problem seems so obvious and common

Tell me it about it 🤣

The only hiccup was that it couldn't really handle decimals, so anything like 0.5 it would break the calculation. I've seen other libraries handle that internally by multiplying the input number by 10000 for example and dividing internally the output by 10000. I would have done that but I think the original devs would be able to handle that more elegantly than I could. I read somewhere on here something about integers, and 0.35 meters is not an int, but that's easy to work around on the client side.

Yep, official advice is if you're using inches or cm, convert to mm. I should probably add that the docs...

[dvdoug]

Glad you got it working 👍

[dvdoug]

Also - cheers @shakethatweight-simon !